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Посвждение 


Кристин. Словами не вмразитБ то, что л думаго о нашеи совместнои жизни. И с 
нежностБК) отношусв к нашеи сем i>e и ко всем нашим семеинмм радостлм. Каждми 
денв моеи жизни наполнен .побош.к) к тебе. 

Адзн (9 лет) и Грант (5 лет). Вм оба вдохновлнли менн, учили менн игратБ и весе- 
ло проводитБ времн. Наблгоденин за тем, как вб 1 росли, доставлнли мне радоств. Мне 
повезло статв частБГО вашеи жизни. И лгоблго и ценго вас болвше всех на свете. 



Предисловие 


Вот мм и снова встретилисБ. Кто бм мог подуматБ? Ага, з.пак) — н должна бмла ото 
предвидетћ! 

Жизнб в браке — один сплошнои «Денн сурка». Если вм не видели зтот филБм, 
посмотрите; вм внезапно поимете, почему одни и те же ошибки приходитсн повто- 
рнтћ снова и снова. Когда Джефф сказал мне, что он не будет писатБ следуклцуго 
книгу, л сразу понила, что ото пустое обегцание. Джефф не может не написатБ 
следуклцук) книгу. Толбко сегоднл мб 1 с ним обсуждали егце одну книгу которуго 
он тоже совершенно не собираетсл писатБ (толбко почему-то уже написал целуго 
главу). Зто у него в крови. Породистал лошадБ рождаетсл длл скачек, а Джефф 
рожден длл того, что 6 б 1 писатБ книги. 

Джефф предсказуем, как смена времен года. Он не может держатБсл подалБше 
от ноликов и единичек на своем жестком диске. И когда iiop.wa.Ti>iii>ie лгоди мирно 
сплт в своих постеллх, внутреннии будилБник Джеффа начинает звонитб где-то в 3 
часа ночи (когда наш 5-летнии сбш залезает в нашу постелБ — егце одно лвление, 
с которБш, похоже, ничего не поделаешБ). Какал-то таинственнал сила направллет 
Джеффа в кабинет и заставллет его мозг решатБ всевозможнБге маленБКие и болБшие 
проблемБц Другим остаетсл лишб перевернутБСл на другои бок и снова заснутБ — 
знан, что Джефф где-то ридом решает зти проблемБ 1 за нас — словно некии кибер- 
супергерои, спасагогции программнБге потоки от преждевременнои гибели. 

Однако Джеффу недостаточно копитб bcio зту информацшо в своем личном 
уголке Вселеннои. Его начинагот терзатБ угрБгзенгш совести — он должен поделитБСн 
своими МБ 1 СЛЛМИ с другими; записатБ их на бумаге. Они словно радиоволнБц кото- 
pbie передаготсл в пространстве, что 6 б 1 их кто-то где-то приннл. И все зто делаетси 
длн вас, дорогои читателБ; перед вами свидетелБСтво его страсти к технологгшм 
Microsoft. 

В зтои книге добавилосБ авторскои мудрости. ВалцисБ на со.тпшпке, Джефф 
становитсл старше, и с течением лет он начинает оглидБшатБСи назад. РазмБшглнн 
о вегцах с более зрелБгх позиции, он переписал главу, посвигценнуго отражениго 
(reflection). Возможно, вбг оцените его позтическии подход к теме. В зтои главе 
рассказано о том, как заставитБ программнБш код задаватБ Bonpocbi о другом коде, 
а также приводлтсн более глубокие рассужденин о том, почему отражение работает 
именно так, а не иначе. Е1аденБте халат, сидпте в кожаное кресло и предаитесБ вбн 
соким размБгшленгшм о своем коде и с.м i>ic. : ie жизни. 

Также в книге добавилсл материал о async/await. Очевидно, зто развитие темБ1 
AsyncEnumerator, о которои Moii лгобимБги говорил какое-то времн назад. Тогда мне 
nopoii казалосБ, что он ни о чем другом говоритБ уже не способен! Правда, после всех 
разговоров н так толком и не запомнила, что зто такое. Джефф работал с группои 
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в «6олбшом М», доводл до ума механизм async/await, и теперБ зтот материал вошел 
в книгу, чтобм порадоватБ читателн. 

Егце одно крупное дополнение к книге вБШБшает у менн болБше всего змоции. 
НадегосБ, все читатели ознакомнтсл с главои о WinRT и возБмут зтот материал 
на вооружение. WinRT — такои термин длн технареи, которое каким-то образом 
означает: «Сделаите Мне Крутое Приложение Длн Моего Планшета — ПРЛМО 
СЕИЧАС!» Да, все верно; зто нован исполнителБнан среда Windows длн сенсорнБ 1 х 
зкранов. Мои дети обожагот кидатвсн птичками в свинеи. Мне нравнтси приложе- 
нгш с цветочками, и определенно планшетБг полезнБг длл образователБНБгх целеи. 
Даите волго фантазии! И пожалуиста, сделаите так, чтобвг зта глава принесла мне 
какуго-нибудв полБзу. Иначе мое терпение с Джеффом и его вечнои работои над 
книгами исснкнет, и н запру его в комнате с внзалвнБши спицами и без злектриче- 
ства. Ввгбираите, программистБг: либо пишем классннге приложенгш с WinRT, либо 
новБгх книг от Джеффа уже не будет! 

Короче говори, Джефф (при вашем неустанном содеиствии) ввгдал очереднои 
шедевр, и наша семвн может вернутБСл к своему нормалвному состонниго. Хотл 
что считатБ нормои? Возможно, состонние работБг над очереднои книгои уже стало 
нормалБНБш. 


В терпеливом ожидании следутцеп книги, 
Кристин Трепс (жена Джеффа) 
октлбрв 2012 г. 



На помоцдб! Спасите Джеффа от впзанип! 



Введение 


В октлбре 1999 года лгоди из Microsoft впервме продемонстрировали мне плат- 
форму .NET Framework, обшелзмковуго среду ввшолненин (Common Language 
Runtime, CLR) и нзмк программировании С#. Все зто произвело на менн силБное 
впечатление: н сразу поннл, что Moii подход к написаниго программного обеспече- 
шш претерпит сугцественнме измененгш. Менн попросили проконсулБтироватБ 
команду разработчиков, и н немедленно согласилсл. Поначалу н думал, что плат- 
форма .NET Framework представллет собои абстрактнуго прослоику между Win32 
API (Application Program Interface, интерфеис прикладного программировангш) 
и моделБГО СОМ (Component Object Model, обЂектнаи моделЂ компонентов). Но 
чем болЂше н изучал платформу ,NET Framework, тем иснее видел, насколЂКО л ее 
недооценивал. В некотором сммсле зто операционнан система. У нее собственнме 
диспетчер виртуалЂнои памлти, система безопасности, фаиловми загрузчик, ме- 
ханизм обработки ошибок, моделБ изолнции приложении (доменм приложении), 
моделћ многопоточности и многое другое. В зтои книге все зти (и многие другие) 
темм освегцаготсл таким образом, чтобм вм могли зффективно проектироватБ 
и реализовмватБ программное обеспечение на зтои платформе. 

Л написал текст зтои книги в октнбре 2012 года, и уже прошло 13 лет с тех пор, как 
н работаго с платформои ,NET Framework и пзмком программировангш С#. За зти 
13 лет 'А создал разнообразнме приложенгш и как консулБтант компании Microsoft 
внес значителБНБш вклад в разработку платформвг .NET Framework. В качестве 
сотрудника своеи компании Wintellect (http://Wintellect.com) н работал со многими 
заказчиками, помогап им проектироватв программное обеспечение, отлаживатБ 
и оптимизироватБ программБг, решатБ их проблемБг, свнзаннБге с .NET Framework. 
ВесБ зтот опбгт помог мне реалпно узнатБ, какие именно проблемБг возникагот 
у лгодеи при работе с платформои .NET Framework и как зти проблемвг решатБ. 
И попБгталси сопроводитБ зтими знангшми все темвг, представленнБге в зтои книге. 


Длл кого зта книга 

Целв зтои книги — о6бнснитб, как разрабаткгватБ приложенгш и многократно ис- 
полБзуемБге классБг длл .NET Framework. В частности, зто означает, что а собира- 
госб рассказатБ, как работает среда CLR и какие возможности она предоставллет 
разработчику. В зтои книге также описБшаготсл различнБге классБг стандартнои 
библиотеки классов (Framework Class Library FCL). Ни в однои книге невозмож- 
но описатБ FCL полностбго — она содержит тбгслчи типов, и их число продолжает 
расти ударнБгми темпами. Так что а остановлгосБ на основнбгх типах, с которБгми 
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должен 6мтб знаком каждми разработчик. И хотн в зтои книге не рассматривагот- 
сн отде./њпо подсистема графического интерфеиса полвзователи Windows Forms, 
система дли построенин клиентских приложении Windows Presentation Foundation 
(WPF), Microsoft Silverlight, веб-службм XML, веб-формм, Microsoft ASP.NET 
MVC, Windows Store Apps и т. д., технологии, описаннме в неи, применимм ко всем 
зтим видам приложении. 

В книге 1 КТ 10 Л 1 )Зук:)тси системм Microsoft Visual Studio 2012, .NET Framework 4.5 
и компилитор C# версии 5.0. Компании Microsoft стараетсл по возможности обе- 
спечиватв обратнуго совместимоств при вмпуске новои версии зтих программнмх 
продуктов, позтому многое из того, что обсуждаетсн в даннои книге, применимо 
и к ранним версиим. Все примерм в книге написанм на нзмке С#, но так как в среде 
CLR можно iiciio.Tb./soiia ri) различнме нзмки программированин, книга пригодитси 
также и тем, кто пишет на других измках программированин. 

ПРИМЕЧАНИЕ 

Примерн кода, приведеннне в книге, можно загрузит с саита компании Wintellect 
(http://Wintellect.com/Books). 

Л и мои редакторм усердно потрудилисг), чтобм датв вам наиболее точпуто, 
свежуто, исчерпмватогцуго, удобнуго, поннтнуго и безошибочнуго информациго. 
Однако даже такан фантастическаи команда не может предусмотретв все. Если вм 
обнаружите в зтои книге ошибки (особенно ошибки в программном коде) или же 
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Глава 1. Моделв вмполненил 
кода в среде CLR 


В Microsoft .NET Framework понвилосб много новмх концепции, технологии и тер- 
минов. ЦелБ зтои главБ1 — датБ обзор архитектурБ1 .NET Framework, познакомитБ 
с новБ 1 ми технологинми зтои платформБ 1 и определитБ терминБц с которБши вб 1 
столкнетесБ при работе с неи. Также в зтои главе изложен процесс построенгш прило- 
женгш или набора распространлемвк компонентов (фаилов), которвге содержат типб 1 
(классБ!, структурБ! и т. п.), и затем обБиснено, как вБшолннетси приложение. 


Компиллцил исходного кода 
в управллемме модули 

Итак, вб 1 решили исполБЗОватБ .NET Framework как платформу разработки. Отлич- 
но! Ваш первБШ шаг — определитБ вид создаваемого приложенгш или компонента. 
Предположим, что зтот вопрос уже решен, все спроектировано, спецификации 
написанБ1 и все готово длл начала разработки. 

Теперв надо вБ1братп азшс программировангш. И зто непростаи задача — ведв 
у разнБгх изБгков имеготсп разнвге возможности. Например, с однои сторонвг, 
<<неуправлиемБ1и код» С/С++ дает доступ к системе на низком уровне. Bbi вправе 
распорижатБСи памнтБго по своему усмотрениго, при необходимости создаватв про- 
граммнпге потоки и т. д. С другои сторонБц Microsoft Visual Basic 6.0 позволнет оченв 
бБ 1 Стро строитБ полБЗОвателБСКие интерфеисБ1 и легко управлитБ СОМ-обвектами 
и базами даннБ 1 х. 

Название средБ1 — обцелзикован среда виполненил (Common Language Runtime, 
CLR) — говорит само за себи: зто среда ввшолненгш, которан подходит длл разнБ1х 
НЗБ1КОВ программировангш. Основнвге возможности CLR (управление памнтвго, 
загрузка сборок, безопасностк, обработка исклгочении, синхронизацин) доступнБ 1 
в лго 6 б 1 х изБшах программировангш, исполвзугогцих зту среду. Например, при об- 
работке ошибок среда вБшолненгш опираетсн на исклгоченгш, а значит, во всех 
нзБшах программировангш, исполБзугогцих зту среду вБшолненгш, сообгценгш об 
ошибках передаготсл при помогци механизма исклгочении. Или, например, среда 
вБшолненгш позволиет создаватв программнБге потоки, а значит, во всех нзвжах 
программировангш, исполБзугогцих зту среду, тоже могут создаватБСи потоки. 
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Фактически во времн вшполнешш программм в среде CLR неизвестно, на каком 
нзмке программированин разработчик написал исходнми код. А зто значит, что 
можно вмбратБ лгобои нзмк программированин, которми позволнет прогце всего 
решитБ конкретнуго задачу. РазрабатБшатБ программное обеспечение можно на 
лгобом пзБше программировангш, если толбко исполкзуемБШ компилптор зтого 
нзБгка поддерживает CLR. 

Так в чем же тогда преимугцество одного нзвгка программировангш перед дру- 
гим? И рассматриваго компилнторБг как средства контроли синтаксиса и анализа 
«правилБности кода». КомпилнторБг провернгот исходнбти код, убеждаготсл, что все 
написанное имеет некии смбшл, и затем генериругот код, описБшагогции решение 
даннои задачи. РазнБ 1 е нзб1Ки программировангш позволнгот разрабатвшатв про- 
граммное обеспечение, исполБзун различнБпг синтаксис. Не стоит недооцениватБ 
значение внгбора синтаксиса нзкгка программировангш. Например, д./ш математи- 
ческих или финансовБ1Х приложении вБгражение мбгсли программиста на лзБше 
APL может сохранитБ много днеи работнг по сравнениго с применением в даннои 
ситуации изБгка Perl. 

Компангш Microsoft разработала компиллторБг длл следугогцих лзбгков про- 
граммировангш, исполвзуемвгх на зтои платформе: C++/CLI, C# (произноситсл 
«си шарп»), Visual Basic, F# (произноситсл «зф шарп»), Iron Python, Iron Ruby 
и ассемблер Intermediate Language (IL). Кроме Microsoft, егце несколпко компании 
и университетов создали компилнторвг, предназначеннвге длн средБг вБгполненин 
CLR. Мне известнБг компшшторБг длл Ada, APL, Caml, COBOL, Eiffel, Forth, Fortran, 
Haskell, Lexico, LISP, LOGO, Lua, Мегсигу, ML, Mondrian, Oberon, Pascal, Perl, Php, 
Prolog, RPG, Scheme, Smalltalk гг Tcl/Tk. 

Рисунок 1.1 иллгострирует процесс компгглнцгги фаилов с исходнбгм кодом. Как 
вггдно ггз рисунка, ггсходнбш код программБг может 6 бгтб написан на лгобом нзнгке, 
поддерживагогцем среду вБгполненин CLR. Затем соответствугогцгги компгглитор 
провернет синтаксис гг аналггзггрует исходнбги код программкг. Вне зависимости от 
тггпа исполБзуемого компшштора резулкгатом компгглнцгги будет нвлнтбсн управлне- 
мип модулв (managed module) — стандартнБги переносимБги исполннемБги (portable 
executable, РЕ) фаил 32-разрпднои (РЕ32) ггли 64-разриднои Windows (РЕ32+), 
которБш требует длн своего вБгполненин CLR. Кстати, управлпемБге сборкгг всегда 
ггсполБзугот преимугцества функции безопасности «предотврагценип вБгполнешш 
даннБгх» (DEP, Data Execution Prevention) и технологиго ASLR (Address Space 
Layout Optimization), применение зтих технологгш повБгшает информационнуго 
безопасностБ всеи системвг. 

КомпилнторБг машинного кода проггзводлт код, орггентированнБш на конкретнуго 
процессорнуго архитектуру, например х86, х64 гглгг ARM. В отлггчгге от зтого, все 
CLR -совместимвге компгглнторБг генериругот IL -код. (Подробнее об IL -коде рас- 
сказано далее в зтои главе.) IL -код ггногда назвгвагот управллемим (managed code), 
потому что CLR управлнет его вБгполнением. 
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Рис. 1.1. Компиллцил исходного кода в управллемме модули 
В табл. 1.1 описанм составнме части управлиемого модулл. 


Таблица 1.1. Части управлнемого модулн 


HacTb 

Описание 

Заголовок РЕ32 или 
РЕ32+ 

СтандартнБШ заголовок РЕ-фаила Windows, аналогичнвш за- 
головку Common Object Lile Lormat (COLL). Фаил c заголов- 
ком в формате РЕ32 может вбшолнлтбсн в 32- и 64-разрнднои 
версилх Windows, а с заголовком РЕ32+ — толбко в 64-раз- 
рнднои. Заголовок обозначает тип фаила: GUI, CUI или DLL, 
он также имеет временнуго метку, показБгвагогцуго, когда фаил 
6бш собран. Длл модулеи, содержагцих толбко IL -код, основ- 
нои обвем информации в заголовке РЕ32(+) игнорируетсл. 

В модуллх, содержагцих машиннвш код, зтот заголовок содер- 
жит сведенил о машинном коде 

Заголовок CLR 

Содержит информациго (интерпретируемуго CLR и утилита- 
ми), которан преврагцает зтот модулв в управлнемБги. Заголо- 
вок вклгочает нужнуго версиго CLR, некоторвге флаги, метку 
метаданнБгх MethodDef точки входа в управллемвш модулБ 
(метод Main), а также месторасположение/размер метаданнБгх 
модулл, ресурсов, строгого имени, некоторвгх флагов и пр. 

Метаданнне 

КаждБги управллемБШ модулБ содержит таблицБ! метаданнБГХ. 
Естб два основнбгх вида таблиц — зто таблицвг, описБшагогцие 
типб1 даннБгх и их членБ1, определеннБге в исходном коде, и та- 
6лицб1, описБшагошие типб1 даннБ1х и их членБ1, на которБ1е 
имеготсл ссбшки в исходном коде 

Код Intermediate 
Language(IL) 

Код, создаваемБн! компиллтором при компиллции исходно- 
го кода. Впоследствии CLR компилирует IL в машиннБге 

КОМаНДБ! 
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КаждБШ компилнтор, предназначеннБш длн CLR, помимо генерированин IL -кода, 
должен также создаватк полнбш метаданние (metadata) длн каждого управлнемого 
модулл. Прогце говори, метаданнвге — зто набор таблиц даннБгх, описБшагогцих то, 
что определено в модуле, например типбг и их членБк В метаданнБгх также естк 
таблнцБ!, указБшагогцие, на что ссБшаетсл управлиемБги модулБ, например на им- 
портируемБге типбг и их члешл. МетаданнБге расширнгот возможности таких старвгх 
технологии, как библиотеки типов СОМ и фаилвг IDL (Interface Definition Language, 
лзБгк описанил интерфеисов). Важно отметитв, что метаданшле CLR содержат 
куда более полнуго информациго. И, в отличие от библиотек типов и IDL -фаилов, 
они всегда свизанБг с фаилом, содержагцим IL -код. Фактически метаданнБге всегда 
встроенБг в тот же ЕХЕ- или DLL -фаил, что и код, так что их нелвзн разделитБ. А по- 
сколБку компилнтор генерирует метаданнБге и код одновременно и привнзБшает их 
к конечному управлиемому модулго, возможностб рассинхронизацгш метаданнБгх 
и описБшаемого ими IL -кода исклгочена. 

МетаданнБге находлт много применении. Перечислим лишб некоторБге из них. 

□ МетаданнБге устрашггот необходимостБ в заголовочнвгх и библиотечнБгх фаилах 
пргг компгглнцгги, так как все сведенгш об упомгшаемвгх типах/членах содержатсн 
в фаиле с реалггзугогцггм их IL -кодом. Компиллторвг могут читатв метаданнБге 
примо ггз управлнемБгх модулеи. 

□ Среда Microsoft Visual Studio ггсполБзует метаданнБге дли облегченин напггса- 
нгш кода. Ее функцгш IntelliSense аналггзирует метаданнБге и сообгцает, какие 
методБг, своиства, собвгтил и поли предпочтителвнБг в данном случае гг какие 
ггменно параметрвг требуготсл конкретнБгм методам. 

□ В процессе верггфикацгги кода CLR исполвзует метаданнБге, что6бг убедитБСи, 
что код совершает толбко «безопаснБге по отношенггго к тггпам» операции. (Про- 
верка кода обсуждаетсл далее.) 

□ Метаданнвге позволнгот сериализоватв полн обвекта, а затем передатк зти дан- 
нБге по сети на удаленнБш компБготер и там провести процесс десериалггзацгггг, 
восстановив обвект и его состоиние на удаленном компвготере. 

□ МетаданнБге позволнгот сборгцггку мусора отслеживатв жизненнБги цггкл обвек- 
тов. Пргг помогци метаданнвгх сборгцик мусора может определггтБ тип обвектов 
и узнатв, какгге ггменно поли в нггх ссвглаготси на друггге обвектБг. 

В главе 2 метаданнвге описанБг более подробно. 

Лзбгкгг программировангш С#, Visual Basic, F# и IL -ассемблер всегда создагот 
модулгг, содержагцие управлнемвги код (IL) и управлнемБге даннБге (даннБге, под- 
держивагогцгге сборку мусора). Длл вБгполнении лгобого управлиемого модулл на 
машггне конечного полвзователн должна 6бгтб установлена среда CLR (в составе 
,NET Framework) — так же, как длл вБгполненгш приложении MFC или Visual 
Basic 6.0 должнбг 6бгтб установленБг библгготека классов Microsoft Foundation Class 
(MFC) ггли DLL -бггблгготеки Visual Basic. 
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По умолчаншо компилнтор Microsoft С++ создает ЕХЕ- и DLL -фаилм, которме 
содержат неуправлиемми код и неуправлнемме даннме. Длл их вмполнешш CLR 
не требуетсл. Однако если вмзватБ компилитор С++ с параметром /CLR в команд- 
Hoii строке, он создаст управлиемме модули (и конечно, дли работм зтих модулеи 
должна 6мтб установлена среда CLR). Компиллтор С++ стоит особннком среди 
всех упомннутБтх компиллторов производства Microsoft — толбко oh позволлет 
разработчикам писатБ как управлнемБш, так и неуправлнемБпг код и встраиватк его 
в единвш модулБ. Зто также единственнБш компшштор Microsoft, разрешагогции 
программистам определнтБ в исходном коде как управлнемвге, так и неуправлнемвге 
типб1 даннБ 1 х. Компилнтор Microsoft предоставлиет разработчику непревзоиден- 
нуго гибкостБ, позволнл исполБЗОватБ сугцествугогции неуправлиемБш код на С/ 
С++ из управлиемого кода и постепенно, по мере необходимости, переходитв на 
управлиемБге типбт 


Обг»единение управллеммх модулеи 
в сборку 

На самом деле среда CLR работает не с модуллми, а со сборками. Сборка (assembly) — 
зто абстрактное поннтие, поннтб смбшл которого на первБ1х порах бпшает нелегко. 
Во-первБ 1 Х, сборка обеспечивает логическуго группировку одного или несколвких 
управлиемБ 1 х модулеи или фаилов ресурсов. Во-вторБ 1 х, зто наименБшаи единица 
многократного исполБЗОванин, безопасности и управленин версгшми. Сборка может 
состолтБ из одного или несколБКих фаилов — все зависит от вБгбраннБгх средств 
и компилнторов. В контексте средвг CLR сборкои назБшаетсл то, что мбг о6бшно 
назБгваем компонентом. 

О сборках доволбно подробно рассказано в главе 2, а здесв достаточно подчерк- 
нутБ, что зто концептуалБное поннтие обозначает способ обБединенгш группБг 
фаилов в единуго сугцностБ. 

Рисунок 1.2 поможет поннтб сутБ сборки. На зтом рисунке изображенБг неко- 
торнге управлнемБге модули и фаилБг ресурсов (или даннвгх), с которБгми работает 
некоторан программа. Зта программа создает единственнБш фаил РЕ32(+), которБпг 
обеспечивает логическуго группировку фаилов. При зтом в фаил РЕ32(+) вклгоча- 
етслч блок даннвгх, назБшаемБги манифестом (manifest). Манифест представллет 
собои о6б1чнбпг набор таблиц метаданнБгх. Зти таблицБг описБшагот фаилБг, которБге 
входнт в сборку, обгцедоступнБге зкспортируемБге типбг, реализованнБге в фаилах 
сборки, а также относнгциесл к сборке фаилвг ресурсов или даннвгх. 

По умолчаниго компилнторБг сами вбшолннгот работу по преобразованиго создан- 
ного управлиемого модули в сборку, то еств компилитор C# создает управлиемБш 
модулБ с манифестом, указБгвагогцим, что сборка состоит толбко из одного фаила. 
Таким образом, в проектах, где еств толбко один управлнемБш модулБ и нет фаилов 
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ресурсов (или фаилов даннмх), сборка и нвлиетси управлиеммм модулем, позто- 
му вмполнитб дополнителЂнме деиствии по компоновке приложенип не нужно. 
В случае если необходимо сгруппироватБ песко пжо фаилов в сборку, потребукзтси 
дополнителБнме инструментм (например, компоновгцик сборок AL.exe) со своими 
параметрами команднои строки. О них подробно рассказано в главе 2. 



Рис. 1.2. Обвединение управллеммх модулеи в сборку 


Сборка позволнет разделитБ логическое и физическое представленин компо- 
нента, поддерживагогцего многократное исполвзование, безопасностБ и управление 
версиими. Разбиение программного кода и ресурсов на разнме фаилм полностбго 
определнетсн желанинми разработчика. Например, редко исполБзуемме типм 
и ресурсм можно вмнести в отделЂнме фаилм сборки. ОтделБнме фаилБ 1 могут за- 
гружатћсн по запросу из Интернета по мере необходимости в процессе ввшолнешш 
программБг. Если некоторБге фаилБ 1 не потребуготси, то они не будут загружатнси, 
что сохранит место на жестком диске и сократит времи установки программвт 
Сборки позволнгот разбитв на части процесс развертБшанин фаилов, при зтом все 
фаилБ1 будут рассматриватБса как единБпг набор. 

Модули сборки также содержат сведенин о других сборках, на которвге они 
ссвшаготси (в том числе номера их версии). Зти даннвге делагот сборку самоописи- 
ваемоп (self-describing). Другими словами, среда CLR может определитв все прнмБШ 
зависимости даннои сборки, необходимвге дли ее ввшолненгш. Не нужно размегцатБ 
никакои дополнителБнои информации ни в системном реестре, ни в доменнои 
службе AD DS (Active Directory Domain Services). Вследствие зтого развертвгватБ 
сборки гораздо прогце, чем неуправлиемБге компонентБг. 
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Загрузка CLR 

Каждал создаваемаи сборка представллет собои либо исполнлемое приложение, 
либо библиотеку DLL, содержашуго набор типов длн исполБЗОванин в исполннемом 
приложении. Разумеетсл, среда CLR отвечает за управление исполнением кода. 
Зто значит, что на компБШтере, вмполннгошем данное приложение, должна 6мтб 
установлена платформа .NET Framework. В компании Microsoft 6бш создан дис- 
трибутивнБШ пакет ,NET Framework длн свободного распространенин, которвш bbi 
можете бесплатно поставлнтв своим клиентам. Некоторвге версии операционнои 
системБ 1 семеиства Windows поставлнготсн с уже установленнои платформои .NET 
Framework. 

Длл того что6б1 поннтб, установлена ли платформа .NET Framework на компбго- 
тере, попробуите наити фаил MSCorEE.dll в каталоге %SystemRoot%\system32. Если 
он еств, то платформа .NET Framework установлена. Однако на одном компвготере 
может 6бмб установлено одновременно несколвко версии .NET Framework. 4 to 6 bi 
определитБ, какие именно версии установленБ1, проверБте содержимое следугогцих 
подкаталогов: 

%SystemRoot%\Microsoft . NET\Framework 
%SystemRoot%\Microsoft . NET\Framework 64 

Компанин Microsoft вклгочила в ,NET Framework SDK утилиту команднои 
строки CLRVer.exe, которам вбшодит список всех версии CLR, установленнБ 1 х на 
машине, а также сообгцает, какаи именно версин средБ 1 CLR исполБзуетсл теку- 
гцими процессами. Длл зтого нужно указатн параметр -all или идентификатор 
интересугогцего процесса. 

Прежде чем переходитБ к загрузке средБ 1 CLR, поговорим поподробнее об осо- 
бенностлх 32- и 64-разрнднБ1х версии операционнои системБ 1 Windows. Если сборка 
содержит толбко управлнемБпт код с контролем типов, она должна одинаково хорошо 
работатв на обеих версинх системББ ДополнителБнои модификации исходного кода 
не требуетсл. Более того, созданнкш компилитором готовбш ЕХЕ- или DLL -фаил 
будет правилБно вбшолнитбсн в Windows версии х86 и х64, а библиотеки классов 
и приложенгш Windows Store будут работатв на машинах с Windows RT (исполб- 
зугогцих процессор ARM). Другими словами, один и тот же фаил будет работатв на 
лгобом компБГОтере с установленнои платформои .NET Framework. 

В исклгочителБно редких случанх разработчикам приходитсл писатБ код, совме- 
стимб1и толбко с какои-то конкретнои версиеи Windows. Обвшно зто требуетсл при 
работе с небезопаснБш кодом (unsafe code) или длн взаимодеиствин с неуправлнемвш 
кодом, ориентированнБш на конкретнуго процессорнуго архитектуру. Длн таких слу- 
чаев у компилнтора C# предусмотрен параметр команднои строки /platf orm. Зтот 
параметр позволнет указатв конкретнуго версиго целевои платформБ1, на которои 
планируетсл работа даннои сборки: архитектуру х86, исполБзуклцуго толбко 32-раз- 
риднуго систему Windows, архитектуру х64, исполБзугогцуго толбко 64-разриднуго 
операционнуго систему Windows, или архитектуру ARM, на которои работает толбко 
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32-разрмдпам Windows RT. Если платформа не указана, компилитор задеиствует 
значение по умолчаниго апусри, которое означает, что сборка может вмполннтбсн 
в лгобои версии Windows. ПолБЗОватели Visual Studio могут указатБ целевуго плат- 
форму в списке Platform Target на вкладке Build окна своиств проекта (рис. 1.3). 
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Рис. 1.3. Определение целевои платформн средствами Visual Studio 


На рис. 1.3 обратите внимание на флажок Prefer 32-Bit. Он доступен толбко в том 
случае, когда в списке Platform Target ввгбрана строка Апу CPU, а длн вкгбранного типа 
проекта создаетсл исполнпемБпТ фаил. Если установитБ флажок Prefer 32-Bit, то 
Visual Studio запускает компилнтор C# с параметром команднои строки /platf orm : 
anycpu32bitpreferred. Зтот параметр указкшает, что исполннемБш фаил должен 
вбшолннтбсн как 32-разриднБш даже на 64-разрчднБгх машинах. Если вашему при- 
ложениго не нужна дополнителБнан памнтБ, доступнан длн 64-разрнднБгх процессов, 
обвшно стоит ввгбратБ именно зтот режим, потому что Visual Studio не поддерживает 
функциго «ИзменитБ и продолжитБ» (Edit-and-Continue) длл приложении х64. 
Кроме того, 32-разриднБге приложенгш могут взаимодеиствоватБ с 32-разриднБши 
библиотеками DLL и компонентами СОМ, если зтого потребует ваше приложение. 

В зависимости от указаннои целевои платформвг C# генерирует заголовок — 
РЕ32 или РЕ32+, а также вклгочает в него требуемуго процессорнуго архитектуру 
(или признак независимости от архитектурвг). Дли анализа заголовочнои инфор- 
мации, вставленнои компилнтором в управлнемвги модулБ, Microsoft предоставлнет 
две утилитБ! — DumpBin.exe и CorFlags.exe. 
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При запуске исполннемого фаила Windows анализирует заголовок ЕХЕ-фаила 
длл определенгш того, какое именно адресное пространство необходимо длл его 
работм — 32- или 64-разрндное. Фаил с заголовком РЕ32 может вмполнитбсл 
в адресном пространстве лгобого из указаннћгх двух типов, а фаилу с заголовком 
РЕ32+ требуетсл 64-разридное пространство. Windows также провериет инфор- 
мацшо о процессорнои архитектуре на совместимоств с заданнои конфигурациеи. 
Наконец, 64-разриднБ1е версии Windows поддерживагот технологшо ввшолненгш 
32-разрнднБ1Х приложении в 64-разрнднои среде, которал назвгваетсл WoW64 
(Windows on Windows64). 

Таблица 1.2 иллгострирует две важнвге вегци. Во-перввгх, в Heii показан тип 
получаемого управлиемого модулл длл разнвгх значении параметра /platform 
команднои строки компилнтора С#. Во-вторБ 1 х, в неи представленБг режимБг вбг- 
полненгш приложении в различнвгх версилх Windows. 


Таблица 1.2. Влипние значенил /platform на получаемБ 1 и модули 
и режим вБтолненил 


Значение 
параметра/ 
platform 

Тип вмходного 
управллемого 
модулл 

х86 Windows 

х64 Windows 

ARM Windows 

RT 

апусри (по 
умолчаншо) 

РЕ32/неза- 

ВИСИМБ1И ОТ 
платформБ! 

ВБшолнлетсл 
как 32-раз- 
рлдное прило- 

жение 

ВБшолнлетсл 
как 64-разрпд- 
ное приложение 

Вмполнлетсл 
как 32-раз- 
рлдное прило- 

жение 

anycpu32bit- 

preferred 

РЕ32/неза- 

ВИСИМБ1И ОТ 
платформБ! 

Вмполнлетсл 
как 32-раз- 
рлдное прило- 

жение 

ВБшолнлетсл 
как WoW64- 
приложение 

Вмполнлетсл 
как 32-раз- 
рлдное прило- 

жение 

х86 

РЕ32Д86 

Вмполнлетсл 
как 32-раз- 
рлдное прило- 

жение 

ВБшолннетсн 
как WoW64- 
приложение 

Не вмполнл- 

етсл 

х64 

РЕ32+Д64 

Не вБшолнл- 

етсл 

ВБШолнлетсн 
как 64-разрпд- 
ное приложение 

Не вбшолнл- 

етсл 

ARM 

PE32+/Itanium 

Не вбшолнл- 

етсл 

Не ВБШолннетсл 

Вмполнлетсл 
как 32-раз- 
рлдное прило- 

жение 


После анализа заголовка ЕХЕ-фаила длл вБгнсненгш того, какои процесс не- 
обходимо запуститБ — 32- или 64-разриднБги, — Windows загружает в адресное 
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пространство процесса соответствугошук) версиго библиотеки MSCorEE.dll (х86, 
х64 или ARM). В системах Windows семеиств х86 и ARM 32-разриднаи версин 
MSCorEE.dll хранитсн в каталоге %SystemRoot%\System32. В системах х64 версил х86 
библиотеки находитсл в каталоге %SystemRoot%\SysWow64, а 64-разриднаи версин 
MSCorEE.dll размегцаетсн в каталоге %SystemRoot%\System32 (зто сделано из сооб- 
ражении обратнои совместимости). Далее основнои поток вмзмвает определеннми 
в библиотеке MSCorEE.dll метод, которми инициализирует CLR, загружает сборку 
ЕХЕ, а затем вмзмвает ее метод Main, в котором содержитси точка входа. На зтом 
процедура запуска управлнемого приложении считаетсл завершеннои 1 . 

ПРИМЕЧАНИЕ 

Сборки, созданнме при помош,и версии 7.0 и 7.1 компиллтора C# от Microsoft, со- 
держат заголовок РЕ32 и не завислт от архитектурм процессора. Тем не менее во 
времл вБ 1 полненил среда CLR считает их совместимими толбко с архитектурои х86. 
Зто повмшает веролтноств максималвно корректнои работм в 64-разрлднои среде, 
так как исполнлемв 1 и фаил загружаетсл в режиме WoW64, которми обеспечивает 
процессу среду, максималино приближеннук) к суш,еству 101 деи в 32-разрлднои 
версии х86 Windows. 


Когда неуправлиемое приложение вмзмвает функцшо Win32 LoadLibrary длл 
загрузки управлиемои сборки, Windows автоматически загружает и инициализи- 
рует CLR (если зто егце не сделано) дли обработки содержагцегосн в сборке кода. 
Лсно, что в такои ситуации предполагаетси, что процесс запугцен и работает, и зто 
сокрагцает областг> применимости сборкгг. В частности, управлиеман сборка, ском- 
пилированнан с параметром /platf orm : х86, не сможет загрузитћсн в 64-разрндном 
процессе, а исполннемБш фаил с таким же параметром загрузитсн в режиме WoW 64 
на компвготере с 64-разриднои Windows. 


Исполнение кода сборки 

Как говорилосБ ранее, управлнемБге модули содержат метаданнБге и программнБги 
код IL. Зто не зависнгцгги от процессора машиннБги лзбгк, разработаннкги компаниеи 
Microsoft после консулБтации с несколБКими коммерческими и академическими 
организацгшми, специализиругогцимиси на разработке избгков и компиллторов. 
IL — избгк более вбгсокого уровнч по сравнениго с болвшинством других машин- 
нбгх избгков. Он позволиет работатв с обвектами и имеет командкг дли созданин 


1 Программнни код может запроситв переменнуго окруженил Is64BitOperatingSystem длл 
того, чтобн определитБ, ВБШолнлетсл ли даннал программа в 64-разрнднои системе Windows, 
а также запроситг> переменнуго окруженил Is64BitProcess, что6бг определитБ, ВБШОлнлетсл 
ли даннан программа в 64-разрндном адресном пространстве. 
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и инициализации обЂектов, вмзова виртуалЂНБ1х методов и непосредственного 
манипулированин злементами массивов. В нем даже естБ командм инициирова- 
нин и перехвата исклгочении дли обработки огнибок. IL можно рассматриватБ как 
обЂектно-ориентированнБги магниннБги нзбгк. 

06бгчно разработчики программиругот на вБгсокоуровневБгх изБгках, таких как 
С#, Visual Basic или F#. КомпиллторБг зтих нзбгков генериругот IL -код. Однако 
такои код может 6бгтб написан и на нзБгке ассемблера, так, Microsoft предоставлиет 
ассемблер IL (ILAsm.exe), а также дизассемблер IL (ILDasm.exe). 

Имеите в виду, что лгобои избгк вбгсокого уровнн, скорее всего, исполвзует лигнб 
частБ возможностеи, предоставлнемвгх CLR. Пргг зтом нзбгк ассемблера IL откркгвает 
доступ ко всем возможностнм CLR. Еслгг вБгбраннБги вами нзбгк программировангш 
не дает доступа именно к тем функцгшм CLR, которвге необходимвг, можно написатБ 
частБ программного кода на ассемблере IL ггли на другом нзкгке программированин, 
позволнгогцем их задеиствоватв. 

УзнатБ о возможностлх CLR, доступнвгх при исполБЗОвании конкретного нзбг- 
ка, можно толбко при изучении соответствугогцеи документации. В зтои кнггге 
сделан акцент на возможностнх средвг CLR и на том, какие из зтих возможностеи 
доступнБг пргг программировангги на С#. Подозреваго, что в другггх книгах и статвнх 
среда CLR рассматриваетсн с точки зренгга другггх нзбгков и разработчики получагот 
представление лишб о тех ее функцгшх, которкге доступнБг при исполБЗОвании опи- 
саннвгх там избгков. Впрочем, если ввгбраннБги избгк регнает поставленнвге задачи, 
такои подход не так уж плох. 

ВНИМАНИЕ 

R думакг, что возможностб легко переклкзчатвсл между лзмками при их теснои ин- 
теграции — чудесное качество CLR. К сожаленик), л также практически уверен, что 
разработчики часто будут проходити мимо нее. Такие лзмки, как C# и Visual Basic, 
прекрасно подходптдлл программированил ввода-вв 1 вода. R3biK APL (А Programming 
Language) — замечателинми лзмк длл инженернмх и финансови 1 х расчетов. Среда 
CLR позволлет написати на C# части приложенил, отвечакзидук) за ввод-вв 1 вод, 
а инженернме расчетм — на лзмке APL. Среда CLR предлагает беспрецедентнми 
уровени интеграции зтих лзи 1 ков, и во многих проектах стоит сервезно задуматмга 
об исполвзовании одновременно несколиких лзмков. 


Дли вБгполненич какого-либо метода его IL -код должен 6бгтб преобразован в 
магниннБге командБг. Зтим занимаетси JIT -компилнтор (Just-In-Time) средкг CLR. 

На рис. 1.4 показано, что происходит при первом ввгзове метода. 

Непосредственно перед исполнением метода Main среда CLR находит все типбг 
даннБгх, на которнге ссБглаетсл программнБги код метода Main. При зтом CLR вбг- 
делиет внутренние структурвг даннвгх, исполБзуемБге длл управленип доступом 
к типам, на которвге еств ссбглки. На рис. 1.4 метод Main ссБглаетсн на единствен- 
нбги тип — Console, и среда CLR вБгделнет единственнуго внутреннгого структуру. 
Зта внутреннпн структура даннвгх содержит по однои записи длн каждого метода, 
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определенного в типе Console. Каждал записБ содержит адрес, по которому мож- 
но наити реализациго метода. При инициализации зтои структурм CLR заносит 
в каждуго записБ адрес внутреннеи недокументированнои функции, содержагцеисн 
в самои среде CLR. Л обозначаго зту функциго DITCompiler. 



Рис. 1.4. nepBbm Bbi30B метода 

Когда метод Main первши раз обрагцаетсн к методу WniteLine, вшзмваетсл 
функцин IITCompilen. Она отвечает за компилицшо IL -кода вшзмваемого метода 
в собственнме командм процессора. ПосколБку IL -код компилируетсл непосред- 
ственно перед вмполнением («just in time»), зтот компонент CLR часто назмвагот 
Ј1Т-компиллтором. 

ПРИМЕЧАНИЕ 

Если приложение исполнлетси в х86 версии Windows или в режиме WoW64, JIT- 
компиллтор генерирует командм ддл архитектурм х86. Длл приложении, ви 1 полнлеммх 
как 64-разрлднме в версии х64 Windows, JIT -компиллтор генерирует командм х64. 
Наконец, если приложение вмполнлетсл в ARM -версии Windows, Ј1Т-компиллтор 
генерирует инструкции ARM. 
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Функции DITCompilen известен вмзмваемми метод и тип, в котором он опреде- 
лен. DITCompiler шцет в метаданнмхсоответствукнцеи сборки IL -код вмзмваемого 
метода. Затем DITCompiler провериет и компилирует IL -код в машиннме коман- 
дм, которме сохрапа iotcm в динамически вБвделенном блоке памити. После зтого 
DITCompiler возврагцаетсн к структуре внутренних даннмх типа, созданнои средои 
CLR, и заменнет адрес вмзмваемого метода адресом блока памити, содержагцего 
готовме машиннме командм. В завершение DITCompiler передает управление коду 
в зтом блоке памлти. Зтот программнми код лвллетсл реализациеи метода WriteLine 
(вариант зтого метода с параметром String). Из зтого метода управление возвра- 
гцаетсл в метод Main, которми продолжает вмполнение в обмчном поридке. 

Рассмотрим повторное обрагцение метода Main к методу WriteLine. К зтому 
моменту код метода WriteLine уже проверен и скомпилирован, так что обрагцение 
к блоку памнти производитсн напрнмуго, без вмзова DITCompiler. Отработав, метод 
WriteLine возврагцает управление методу Main. На рис. 1.5 показано, как вмгллдит 
ситуацин при повторном обрагценгш к методу WriteLine. 



Рис. 1.5. Повторниш Bbi30B метода 
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Снижение производителБности наблгодаетсл толбко при первом m.iaonc метода. 
Все последуговдие обрашенин вбшолннготсн <<на максималБнои скорости», потому 
что повторнан верификацин и компилнцин не производлтсн. 

JIT -компилитор хранит машиннвге командБ 1 в динамическои памлти. Зто зна- 
чит, что скомпилированнБш код уничтожаетсн по завершении работБ1 приложенин. 
Длл повторного ввгоова приложенгш или длл параллелвного запуска его второго 
зкземплнра (в другом процессе операционнои системБг) JIT -компилнтору придетсн 
заново скомпилироватБ IL -код в машиннвге командвк В зависимости от приложенин 
зто может привести к сугцественному повБгшениго затрат памлти по сравнениго 
с низкоуровневБгми приложением, у которнгх находлгциисн в памнти код доступен 
толбко длн чтенгш и совместно исполвзуетсл всеми зкземплирами приложенгш. 

Длл болБшинства приложении снижение производителвности, свлзанное с ра- 
ботои JIT -компилнтора, незначителвно. Болбшинство приложении раз за разом 
обрагцаетси к одним и тем же методам. На производителвности зто сказБгваетсл 
толбко один раз во времл ввшолненгш приложенгш. К тому же вБшолнение самого 
метода обнгчно занимает болнше времени, чем обрагцение к нему. 

Также следует учеств, что JIT -компшштор средвг CLR оптимизирует машиннБпг 
код аналогично компилнтору неуправлиемого кода С++. И опитб же: создание 
оптимизированного кода занимает болвше времени, но при вБшолнении он гораздо 
производителБнее, чем неоптимизированнБш. 

Естб два параметра компилитора С#, влгшгогцих на оптимизациго кода, — 
/ optimize и /debug. В следугогцеи таблице показано их влгшние на качество 
IL -кода, созданного компшштором С#, и машинного кода, сгенерированного JIT- 
компшштором. 


Параметри компилетора 

Качество IL -кода 
компиллтора 

Качество машинного 
Ј1Т-кода 

/optimize- /debug- 

(по умолчаниго) 

Неоптимизированнћги 

ОптимизированнБги 

/optimize-/debug(+/full/ 
pdbonly) 

НеоптимизированнБги 

НеоптимизированнБги 

/optimize+/debug(-/+/full/ 
pbdonly) 

Оптимизированнвги 

ОптимизированнБги 


С параметром /optimize- компилнтор C# генерирует неоптимизированнБпг IL- 
код, содержагцгш множество пуствгх команд (no-operation, NOP). Зти командкг пред- 
назначенБг длн поддержки функции «ИзменитБ и продолжитБ» (edit-and-continue) 
в Visual Studio во времн процесса отладки. Они также упрогцагот процесс отладки, 
позволлл расставлитБ точки останова (breakpoints) на управлигогцих командах, 
таких как for, while, do, if, else, a также блоках try, catch и finally. Bo времн 
оптимизации IL -кода компилнтор C# удалнет зти постороннгге командвг, усложннн 
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процесс отладки кода, но зато оптимизирун поток управленин программои. Кроме 
того, возможно, некоторме оценочнме функции не вмполннготсн во времн отладки. 
Однако IL -код менБше по размерам, и зто уменћшает резулБтиругогции размер ЕХЕ- 
или DLL -фаилов; кроме того, IL -код легче читатБ тем, кто обожает исследоватБ 
IL -код, пБгтаисБ понитб, что именно породил компшштор (например, мне). 

Кроме того, компиллтор строит фаил PDB (Program Database) толбко при 
задании параметра /debug(+/full/pdbonly). Фаил PDB помогает отладчику 
находитБ локалБНБге переменнБге и свнзБшатБ командБ1 IL с исходнбш кодом. 
Параметр /debug : f ull сообгцает JIT -компилнтору о том, что вбг намеренБг заннтБСн 
отладкои сборки; JIT -компилнтор сохраннет информациго о том, какои машин- 
нбш код 6 бш сгенерирован длн каждои командвг IL. Зто позволлет исполвзоватБ 
функциго JIT -отладки Visual Studio длн свизБшангш отладчика с уже работагогцим 
процессом и упрогценгш отладки кода. Без параметра / debug:full компшштор по 
умолчаниго не сохраннет информациго о соответствии между IL и машиннвш кодом; 
зто несколБКО ускорнет компилнциго и сокрагцает затратнг памлти. Если запуститн 
процесс в отладчике Visual Studio, то JIT -компилитор будет отслеживатв инфор- 
мациго о соответствии IL и машинного кода (независимо от состоннгш параметра / 
debug), если толбко вбг не снимете флажок Suppress JIT Optimization On Module Load 
(Managed Only) в Visual Studio. 

При создангш нового проекта C# в Visual Studio в отладочнои конфигурации 
проекта устанавливаготси параметрвг /optimize и /debug :f ull, а в конфигурации 
ввшуска - параметрБг /optimize+ и /debug:pdbonly. 

Разработчиков с опбгтом написангш неуправлиемого кода С или С++ обвшно 
беспокоит, как все зто сказвшаетсл на бБгстродеиствии. Ведв неуправлнемБги код 
компилируетсн длн конкретного процессора и при вБгзове может просто вбг- 
полнитбси. В управлиемои среде компилнцгш кода состоит из двух фаз. Сначала 
компилитор проходит по исходному коду, вбгполнни максималБно возможнуго 
работу по генерированиго IL -кода. Но длл ввшоленнин кода сам IL -код должен 
6 бгтб откомпилирован в машиннБге командБг во времн вБшолненгш, что требует 
вБгделенгш дополнителБнои памити, которан не может исполБЗОватБСи совместно, 
и дополнителБНБгх затрат процессорного времени. 

И и сам пришел к CLR с опбгтом программировангш на С/С++ гг менн сгглбно 
беспокогглгг дополнггтелБНБге затратБг. ДеиствггтелБно, вторан стадгш компгглицгггг, 
происходлгцаи во времн вБгполненггн, замедлнет вБгполненгге гг требует вБгделенгш 
дггнамическои памнтгг. Однако компангш Microsoft основателБно потрудиласБ над 
оптимггзацггеи, чтобнг свести зти дополнителвнБге затратБг к мггнггмуму. 

Если вбг тоже скептическгг относитесн к двухфазнои компгглицгггг, обизателвно 
попробуите построггтБ прггложенгш гг ггзмеркге ггх бБгстродеиствгге. Затем проделаите 
то же самое с какггмгг-нггбудБ нетрггвггалБНБгмгг управлиемБгмгг прггложенггнмгг, соз- 
даннБгмгг Microsoft гглгг другггми компанггнми. Вас удггвит, насколвко зффектггвно 

ОНГГ ВБГПОЛННГОТСН. 

Трудно поверггтБ, но многгге специалистБг (вклгочан менн) считагот, что управлне- 
мвге прггложенггн способнпг даже превзоитгг по проггзводителБностгг неуправлнемБге 
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приложенин. Зто обЂнсниетсл многими причинами. Например, в тот момент, когда 
JIT -компилнтор компилирует IL -код в машиннми код во времн вмполненил, он 
знает о среде вмполненгш болЂше, чем может знатБ неуправлиемми компилнтор. 
Перечислим некоторме возможности повмшешш производителБности управлнемого 
кода по сравненшо с неуправлнеммм: 

□ JIT -компилнтор может определитћ, что приложение вмполннетсн на процессоре 
Intel Pentium 4, и сгенерироватБ машиннБп! код со специалБНБши командами, 
поддерживаемБши Pentium 4. 06бшно неуправлнемБге приложенин компилиру- 
готсн с самБ1м обгцим набором команд и не исполкзугот специалБНБге командБц 
способнБге ПОВБ1СИТБ зффективностБ приложенгш. 

□ JIT -компилнтор может определитБ, что некоторое условие на том компвготере, 
на котором он вБшолннетсл, всегда оказвшаетсл ложнбш. Допустим, метод со- 
держит следуклции фрагмент: 

if (numberOfCPUs > 1 ) { 

} 

Если компБГОтер оснагцен всего одним процессором, то JIT -компилитор не 
будет генерироватБ машиннБге командБг длл указанного фрагмента. В зтом слу- 
чае машиннБпг код оптимизируетси дли конкретнои машинБг, а следователБно, 
занимает меннше места и бБгстрее вБшолннетсн. 

□ CLR может профилироватБ вБшолннемуго программу и перекомпилироватБ IL 
в машиннБш код в процессе ввшолненгш. ПерекомпилированнБпг код реоргани- 
зуетсл длл сокрагценгш ошибочного прогнозировангш переходов на основангш 
наблгодаемБгх закономерностеи вБшолненгш. Текугцие версгш CLR такуго воз- 
можностб не поддерживагот, но возможно, она понвитси в будугцих версилх. 
Зто лишб некоторвге из причин, по которвгм в будугцем управлиемвги код 

может превзоити по производителвности неуправлиемБги код. Как и уже сказал, 
в болБшинстве приложенгш достигаетсл вполне неплохаи производителвностБ и в 
будугцем стоит ожидатв ее улучшенгш. 

Если ваши зкспериментБ 1 показБгвагот, что JIT -компилитор не обеспечивает 
вашему приложениго необходимого уровнн производителвности, возможно, вам 
стоит восполБЗОватБСл утилитои NGen.exe из пакета .NET Framework SDK. Зта 
утилита компилирует весБ IL -код сборки в машиннБш код и сохраннет его в фаиле 
на диске. В момент ввшолненгш при загрузке сборки CLR автоматически провернет, 
сугцествует ли заранее откомпилированнаи версгш сборки, и если сугцествует — за- 
гружает ее, так что компилнцгш во времн ввшолненгш уже не требуетсл. Учтите, 
что NGen.exe приходитсн осторожно строитБ предположенгш относителпно фак- 
тическои средБг вБшолнении, позтому код, генерируемБш NGen.exe, будет менее 
оптимизированнБш, чем код Ј1Т-компшштора. 

Также при анализе производителБности может пригодитБСи класс System. 
Runtime.ProfileOptimization. Он заставлнет CLR сохранитв (в фаиле) инфор- 
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мациго о том, какие методм проходлт JIT -компилнцшо во времн вмполненин при- 
ложенин. Если машина, на которои работает приложение, оснашена несколБКими 
процессорами, при будутцих запусках приложенин JIT -компилнтор параллелБно 
компилирует зти методм в других программнмх потоках. В резулкгате прило- 
жение работает бмстрее, потому что псско./њко методов компилируготсл парал- 
лелБно, причем зто происходит во времи инициализации приложенил (вместо 
Ј IT -компи лиции). 

IL -код и верификацил 

IL нвлнетсн стековБш лзбгком; зто означает, что все его инструкции заноснт операндБг 
в исполнителБНБпг стек и извлекагот резулвтатБ1 из стека. IL не содержит инструкции 
дли работБг с регистрами, и зто упрогцает создание новбгх нзбгков и компилнторов, 
генериругогцих код длн CLR. 

Инструкции IL также ивлпготсл нетипизованнБгми. Например, в IL имеетсл 
инструкцин длл сложенгш двух последних операндов, занесеннвгх в стек. У ин- 
струкции сложенгш нет двух разделвнвгх версии (32-разриднои и 64-разриднои). 
При вБшолненгпг инструкцгш сложенгш определнет типбг операндов, храннгцггхсп 
в стеке, и ввшолннет соответствугогцуго операциго. 

Однако, на мои взглнд, самое болвшое преимугцество IL -кода состоит даже не 
в том, что он абстрагирует разработчика от конкретного процессора. IL -код обеспе- 
чивает безопасноств приложенгш и его устоичивостБ перед ошибками. В процессе 
компилнции IL в машиннБге инструкции CLR вБшолннетсл процедура, назБгваемаи 
верификациеп — анализ вБгсокоуровневого кода IL и проверка безопасности всех 
операции. Например, верификацгш убеждаетсл в том, что каждвги метод вбгзбг- 
ваетсл с правилБНБш количеством параметров, что все передаваемвге параметрБг 
ггмегот правгглБНБш тип, что возврагцаемое значенгге каждого метода исполвзуетсп 
правгглБно, что каждпги метод содержит ггнструкцггго return гг т. д. Всн ггнформацгш 
о методах гг типах, ггсполБзуемаи в процессе верггфикации, хранитси в метаданнвгх 
управлиемого модули. 

В системе Windows каждвги процесс обладает собственнБгм вггртуалБНБгм адрес- 
нбгм пространством. НеобходггмостБ разделенгш адреснБгх пространств обЂнсгшетсн 
тем, что код приложешш в прггнцггпе ненадежен. Ничто не мешает приложениго 
вБгполнггтБ операцггго чтенгш гглгг запггси по недопустимому адресу памнти (гг к со- 
жаленггго, зто часто проггсходит на практггке). Размегценгге процессов Windows в ггзо- 
лированнвгх адреснБгх пространствах обеспечивает загцгггценностБ гг стабгглБностБ 
системБг; одггн процесс не может повредитБ другому процессу. 

Однако верггфикацгш управлиемого кода гарантггрует, что код не будет не- 
корректно обрагцатБСн к памнтгг гг не сможет повредитБ вБгполненггго кода другого 
приложенгш. Зто означает, что вбг можете запуститБ несколБКО управлнемБгх пргг- 
ложенгги в одном виртуалвном адресном пространстве Windows. 

Так как процессвг Windows требугот значггтелБНБгх затрат ресурсов операцион- 
нои системвг, из6бгток их в системе снггжает производителвностБ гг огранггчггвает 
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доступнме ресурсм. Сокрашение количества процессов за счет запуска несколБких 
приложении в одном процессе операционнои системм улучшает производителБ- 
ностб, снижает затратБ1 ресурсов и обеспечивает такои же уровенв затцитБц как 
если 6ki каждое приложение располагало собственннш процессом. Зто егце одно 
преимугцество управлнемого кода по сравненгпо с неуправлиемБш. 

Итак, CLR предоставлиет возможностб ВБШолненил несколнких управлиемБ 1 Х 
приложении в одном процессе операционнои системБ1. Каждое управлиемое при- 
ложение вБшолннетсн в домене приложении (AppDomain). По умолчаншо каждвш 
управлнемБпт ЕХЕ-фаил работает в отделвном адресном пространстве, состолгцем 
из одного домена. Тем не менее процесс, обеспечивагогции размегцение (хостинг) 
CLR — например, IIS (Internet Information Services) или Microsoft SQL Server, — 
может запуститв несколБКО доменов приложении в одном процессе операционнои 
системБт Обсуждениго доменов приложении посвнгцена одна ггз частеи главвг 22. 

Небезопаснми код 

По умолчаниго компилнтор C# компании Microsoft генерирует безопаснБги код. 
Под зтггм термином понимаетсн код, безопасностк которого подтверждаетсн в про- 
цессе верификации. Тем не менее компилнтор Microsoft C# также позволнет раз- 
работчикам писатв небезопаснБги код, способнБги напрнмуго работатн с адресами 
памнти и манггпулироватБ с баитами по зтггм адресам. Как правило, зти чрезввгчаино 
могцнБге средства применнготсл дли взаимодеиствгш с неуправлнемвгм кодом или 
длл оптггмизации алгоритмов, критичнвгх по времени. 

Однако исполБЗОвание небезопасного кода создает значителБНБш рггск: небезопас- 
нбги код может повредитБ структурБг даннБгх и исполБЗОватБ (или даже создаватБ) 
унзвимости в системе безопасности. По зтои причине компилнтор C# требует, чтобвг 
все методвг, содержагцие небезопаснБги код, помечалисБ клгочевБгм словом unsafe, 
а пргг компилнции исходного кода исполБЗОвалси параметр компилнтора /unsafe. 

Когда JIT -компилитор пвгтаетсл откомпилироватБ небезопаснБги метод, он 
сначала убеждаетсл в том, что сборке, содержагцеи метод, бвглгг предоставленвг 
разрешенин System.Security.Permissions .SecurityPermission с установлен- 
нбгм флагом SkipVerification изперечисленгш System.Security.Permissions. 
SecurityPermissionFlag. Если флаг установлен, JIT -компшштор компилирует 
небезопаснБги код и разрешает его вБгполнение. CLR доверлет зтому коду и на- 
деетсн, что примои доступ к памитгг и манггпулпцгги с баитами не причинит 
вреда. Если флаг не установлен, JIT -компшштор ввгдает исклгочение System. 
InvalidProgramException или System.Security.VerificationException, предот- 
врагцаи вБгполнение метода. Скорее всего, в зтот момент приложение авариино 
завершитсл, но по краинеи мере без причиненгш вреда. 

Компанин Microsoft предоставлиет утилиту PEVerify.exe, которал проверлет 
все методвг сборкгг и сообгцает обо всех методах, содержагцих небезопаснБги код. 
Возможно, вам стоит запуститв PEVerify.exe длн всех сборок, на которвге вбг ссБгла- 
етесБ; зто позволггт узнатв о возможнбгх проблемах с запуском ваших приложении 
по интрасети или Интернету. 
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ПРИМЕЧАНИЕ 

По умолчаниио сборки, загружаемме с локалинои MaiimHbi или по сети, обладакот 
полннм доверием; зто значит, что им разрешено вмполнение чего угодно, вклкочал 
небезопаснв 1 и код. Однако по умолчанико сборки, вмполнчемн 1 е по Интернету, не 
получакот разрешении на вмполнение небезопасного кода. Если они содержат не- 
6e3onacHbin код, вмдаетсп одно из упомпнутв 1 х исклкочении. Администратор или 
конечнии полизователв может изменити зти настроики по умолчанико, однако в зтом 
случае он несет полнуко ответственности за поведение зтого кода. 


Следует учитмватћ, что верификации требует доступа к метаданнмм, содержа- 
тцимси во всех зависиммх сборках. Таким образом, когда вм испо. њзустс PEVerify 
длн проверки сборки, программа должна 6мтб способна наити и загрузитБ все упо- 
минаемвге сборки. Так как PEVerify исполБзует CLR длн поиска зависимкгх сборок, 
при зтом исполБзуготсн те же правила привизки и поиска, которвге обвгчно приме- 
ннкзтси при исполнении сборок. Зти правила будут рассмотренБг в главах 2 и 3. 

IL и за!цита интеллектуалБнои собственности 

Р1екоторБ1х разработчиков беспокоит, что IL не обеспечивает достаточного уровнп 
загцитБ 1 интеллектуалБнои собственности длл их алгоритмов. Иначе говорн, они 
полагагот, что кто-то другои может восполвзоватБСн дизассемблером IL, взнтб по- 
строеннБпг ими управлиемБш модулБ и легко восстановитБ логику кода приложенин. 

Да, IL -код работает на более вбгсоком уровне, чем болвшинство других ассем- 
блеров, и в обгцем случае дизассемблирование IL -кода вБшолниетси относителБно 
просто. Однако при реализацгш кода, работагогцего на стороне сервера (веб-служба, 
веб-форма или хранимаи процедура), сборка паходитси на сервере. Посколвку по- 
CTopoHHiiii не сможет обратитБСн к сборке, он не сможет и восполБЗОватБСн лго6бши 
программами дли просмотра IL — ваша интеллектуалвнаи собственностБ в полнои 
безопасности. 

Если вас беспоконт распространиемБге сборки, исполкзуите «маскировочнБге» 
утилитБ 1 от независимБ 1 х разработчиков. Такие программБ 1 шифругот все закрБ1ТБге 
символические имена в метаданнБ 1 х сборки. Постороннему будет трудно расшиф- 
роватБ такое имн и поннтб назначение каждого метода. Учтите, что маскировка 
предоставллет лишб относителБнуго загциту, потому что среда CLR должна в какои- 
то момент получитв доступ к IL -коду длл его JIT -компилнции. 

Если вб1 не считаете, что маскировка обеспечивает желаемвш уровенБ загцитБ 1 
интеллектуалБнои собственности, рассмотрите возможностб реализации более 
секретнБ1х алгоритмов в неуправлнемом модуле, содержагцем машиннвге командБ1 
вместо IL и метаданнБ 1 х. После зтого вб 1 сможете исполБЗОватБ средства взаимодеи- 
ствгш CLR (при наличгш достаточшдх разрешении) дли работБ 1 с неуправлнемБши 
частлми ваших приложении. Конечно, такое решение предполагает, что вас не 
беспокоит возможностб дизассемблированин машиннвш команд неуправлиемого 
кода. 


Библиотека FCL 47 


NGen.exe 

Программа NGen.exe, входнгцан в поставку .NET Framework, может исполБЗОватБСн 
длл компилнции IL -кода в машиннми код при установке приложенин на машине 
полБЗОвателн. Так как код компилируетсл на стадии установки, Ј1Т-компилитору 
CLR не приходитсл компилироватБ его во времн вБшолненин, что может улучшитБ 
бБШтродеиствие приложенгш. Программа NGen.exe полезна в двух ситуацгшх. 

Ускорение запуска приложенин. Запуск NGen.exe ускорлет запуск, потому что 
код уже откомпилирован в машиннуго форму, и компилццшо не нужно вбшолнитб 
на стадии вБшолненгш. 

Сокраш,ение рабочего набора приложенин. Если bki ожидаете, что сборка бу- 
дет загружатБСн в несколвких процессах одновременно, обработка ее программои 
NGen.exe может сократитв рабочии набор приложенгш. Дело в том, что NGen.exe 
преобразует IL в машиннвш код и сохраннет резулктат в отделвном фаиле. Зтот 
фаил может отображатнсп на памитн в несколвких адреснБ1х пространствах одно- 
временно, а код будет исполвзоватБСи совместно, без исполвзовашш каждвгм про- 
цессом собственного зкземплнра кода. 


Библиотека FCL 

Одним из компонентов .NET Framework нвлнетсн FCL (Framework Class Library) — 
набор сборок в формате DLL, содержагцих несколвко тбгслч определении типов, 
каждвш из которБгх предоставлиет некоторуго функционалвностБ. Компанин 
Microsoft разрабатБгвает дополнителБнвге библиотеки — такие, как Windows Azure 
SDK и DirectX SDK. Зти библиотеки содержат егце болкше типов, предоставлни 
в ваше распорижение егце болвше функционалвности. Сеичас, когда Microsoft с 
феноменалБнои скоростБК) вБшускает огромное количество библиотек, разработ- 
чикам стало как никогда легко исполБЗОватБ технологии Microsoft. 

Ниже перечисленБ 1 некоторБге разновидности приложении, которвге могут 
создаватвсц разработчиками при помогци зтих сборок: 

Веб-службм. Технологии Microsoft ASP.NET XML Web Service и Windows 
Communication Foundation (WCF) позволшот оченв легко создаватк методБ 1 длл 
обработки сообгцении, передаваемБ 1 х по Интернету. 

Приложенин Web Forms /приложенин MVC на базе HTML. Как правило, 
приложенгш ASP.NET обрагцаготсл с запросами к базам даннвш и вБИОвами к веб- 
службам, обБединнгот и филБтругот полученнуго информациго, а затем представлнгот 
ее в браузере с исполвзованием расширенного полБЗОвателвского интерфеиса на 
базе HTML. 

Приложенин Windows с расширеннћш графическим интерфеисом. Вместо 
реализации полБЗОвателБСКого интерфеиса приложении в виде веб-страниц мож- 
но исполвзоватБ более могцнуго и вБШОкопроизводителБнуго функционалБностБ, 
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предоставлиемуго технологиими Windows Store, WPF (Windows Presentation 
Foundation) и Windows Forms. Такие приложенгш могут исполБЗОватБ собмтии 
злементов управленин, менкз, сенсорного зкрана, ммши, пера и клавиатурм, а также 
могут обмениватБСн информациеи с операционнои системои, вБвдаватћ запросБ1 
к базам даннБ1х и полБЗОватБСн веб-службами. 

КонсолБНБге приложенин Windows. КонсолБНБ 1 е приложении — простои 
и бБ 1 СтрБпг вариант дли создангш приложении с минималБнвши потребностими в 
полвзователБСКом интерфеисе. КомпиллторБг, утилитБг и вспомогателБНБге инстру- 
ментм часто реализуготсн в виде консолбнмх приложении. 

Службв! Windows. Да, теперн стало возможнбш построение служб (services), 
управлнемБгх через Windows SCM (Service Control Manager) c исполБЗОванием 
.NET Framework. 

Хранимћге процедурБ! баз даннћгх. СерверБг баз даннБгх Microsoft SQL Server, 
IBM DB2 и Oracle дагот возможностб разработчикам писатк свои хранимвге про- 
цедурБг с исполБЗОванием ,NET Framework. 

Библиотеки компонентов. .NET Framework позволнет создаватв автономнБге 
сборки (компонентБг) с типами, легко встраиваемБши в приложенин всех упоми- 
навшихсн разновидностеи. 

ВНИМАНИЕ 

В Visual Studio также предусмотрен тип проекта Portable Class Library дла созданип 
сборок библиотек классов, работакотих с разнБ 1 ми видами приложении, вклкочаа 
классические приложенип .NET Framework, приложении Silverlight, Windows Phone, 
Windows Store и Xbox 360. 

Так как FCL содержит буквалвно тбгсичи типов, взаимосвнзаннме типбг обведи- 
ниготси в одно пространство имен. Например, пространство имен System (которое 
вам стоит изучитв как можно лучше) содержит базовкш тип Object — «предок» 
всех осталвнБгх типов в системе. Кроме того, пространство имен System содержит 
типм длл целмх чисел, символов, строк, обработки исклгочении и консолбного 
ввода-вБшода, а также набор вспомогателБНБгх типов, осугцествлнгогцих безопаснвге 
преобразованин между типами даннвгх, форматирование, генерирование случаинвгх 
чисел и вбшолннгогцих математические функции. Все приложенин исполнзугот типбг 
из пространства имен System. 

Чтобвг исполБЗОватБ возможности FCL, необходимо знатв, какое пространство 
имен содержит типбг, предоставлнгогцие нужнуго функционалБноств. Многие типбг 
поддерживагот настроику своего поведенгш; длн зтого тип просто обБнвлнетси про- 
изводнбш от нужного типа FCL. ОбБектно-ориентированнан природа платформвг 
проивлнетсн в том, как ,NET Framework предоставлнет разработчикам единуго 
парадигму программировангш. Кроме того, разработчик может легко создаватв 
собственнБге пространства имен, содержагцие его типбн Зти пространства и типбг 
легко интегрируготсн в парадигму программировангш. По сравнениго с парадигмои 
программировангш Win32 новбпг подход значителнно упрогцает процесс разработки. 
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Болбшинство пространств имен в FCL содержит типм, которме могут исполб- 
зоватБСи в приложенинх лгобмх видов. В табл. 1.3 перечисленм некоторме обгцие 
пространства имен и основнме области примененгш типов зтих пространств. Зто 
O'iein, маленвкаи вмборка доступнмх пространств — чтобм болћше узнатБ о по- 
стоннно расширмкниемси множестве пространств имен, создаваеммх компаниеи 
Microsoft, oopaiuaiiTCCb к документации различнмх пакетов Microsoft SDK. 


Таблица 1.3. Некоторне пространства имен FCL 


Пространство имен 

Описание содержимого 

System 

Bce базовне типбг, исполвзуемвге в приложенилх 

System.Data 

Tiinbi длл взаимодеиствил с базами даннБ 1 х и обработки данннх 

System.IO 

Типи потокового ввода-вивода, обхода дерева каталогов и фаилов 

System.Net 

Тиш >1 длл низкоуровневнх сетевБгх коммуникации и исполвзова- 
нин распространеннБгх протоколов Интернета 

System. Runtime. 
InteropServices 

Tiinbi, позволлклцие управллемому коду работатБ с неуправлле- 
мБ 1 ми платформеннБ 1 ми средствами (компонентами СОМ, функ- 
цилми Win32 и DLL -библиотек) 

System.Security 

Типб 1 запгитБ! даннБ 1 х и ресурсов 

System.Text 

Типб! длл работБ 1 с разнБ 1 ми кодировками (такими, как ANSI 
и КЗникод) 

System.Threading 

Типм асинхроннмх операции и синхронизации доступа 
к ресурсам 

System.Xml 

Tiinbi длл обработки схем и даннБ 1 х XML 


Зта книга посвнгцена CLR и типам обгцего назначенин, тесно взаимодеиству- 
к)гцим с CLR. Таким образом, ее содержимое актуалгшо длн всех программистов, 
занимакзгцихсн разработкои приложении и компонентов длл CLR. О конкретнмх 
разновидностлх приложении — веб-служб, приложении Web Forms/MVC, WPF 
и т. д. — написано много замечателБнмх книг, которБге станут хорошеи отправнои 
точкои длл разработки ваших собственшлх приложении. В зтои книге н предоставллго 
информациго, которан относитсл не к конкретному типу приложении, а к платформе 
разработки. Прочитав зту книгу вместе с другои книгои, посвнгценнои конкретнБгм 
приложенгшм, вбг сможете легко и зффективно создатв приложение нужного типа. 


CTS 


Веронтно, вб1 уже поннли, что самое важное в CLR — типбг, предоставлнгогцие функ- 
ционалБностБ вашим приложенгшм и другим типам. Механизм типов позволнет 
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коду, написанному на одном л.знкс программированин, взаимодеиствоватБ с кодом, 
написаннмм на другом измке. Посколбку типм занимагот централБное место в CLR, 
компании Microsoft разработала формалћнуго спецификациго CTS (Common Туре 
System), котораи описмвает способ определенгш и поведение типов. 

ПРИМЕЧАНИЕ 

Компанил Microsoft предоставллет CTS вместе с другими частлми .NET Framework 
(форматм фаилов, метаданнме, IL, механизм вмзова P/lnvoke и т. д.) в органкоми- 
тет ЕСМА с uenbio стандартизации. Стандарт назмваетсп CLI (Common Language 
Infrastructure) и определлетса спецификациеи ЕСМА-335. Кроме того, компанил 
Microsoft предоставила отделвнме части FCL, пзик программированич C# (ЕСМА- 
334) и чзмк программированип C++/CLI. Информацич об зтих отраслевмх стандар- 
тах доступна на саите ЕСМА по адресу http://www.ecma-international.org. Bbi также 
можете обратитБса на саит Microsoft: http://msdn.microsoft.com/en-us/netframework/ 
aa569283.aspx. 

Согласно спецификации CTS, тип может содержатБ пу.п, и более членов. Под- 
робнме описангш всех возможнмх членов типов приведенм в части II книги, а пока 
'А ограничусћ краткими вводнмми описангшми: 

□ Поле — переменнал, ивлнгогцансн частБГО состоннгш обвекта. Поли идентифи- 
цируготси именем и типом. 

□ Метод — функцгш, вБгполннгогцан операциго с обвектом, часто с изменением его 
состоингш. Метод обладает именем, сигнатурои и модификаторами. Сигнатура 
определнет количество параметров (и поридок их следовангш), типбг параме- 
тров, наличие возврагцаемого значенгш, и если оно имеетсн — тип значенгш, 
возврагцаемого методом. 

□ Своиство — с точки зренип вБгзвгвагогцеи сторонвг вбгглпдит как поле, но 
в реализации типа представлпет собои метод (или два). Своиства позволпгот 
организоватв проверку параметров или состоннгш обпекта перед обрагцением 
к значениго и/или вбгчислитб его значение толбко при необходимости. Кроме 
того, онгг упрогцагот синтаксис работкг с даннБгмгг и позволнгот создаватв «полн», 
доступнБге толбко длл чтенгш или записи. 

□ Собмтие — исполБзуетсп длн созданип механизма оповегценгш между обпектом 
и другими заинтересованнБгми обБектами. Например, кнопка может поддержи- 
ватБ собБгтие, оповегцагогцее другие обпектвг о гцелчке на негт. 

CTS также задает правила видимости типов и доступа к членам типа. Например, 
помечап тип как открвгтБги (клгочевое слово public), вбг тем самБгм зкспортируете 
зтот тип, делан его видимбгм и доступнБгм длн лгобои сборки. С другои сторонкг, по- 
метка типа на уровне сборки (клгочевое слово internal в С#) делает его видимбгм 
и доступнБгм длп кода тои же сборки. Таким образом, CTS устанавливает правила, 
по которвгм сборки формиругот границу видимости типа, а CLR обеспечивает вбг- 
полнение правил видимости. 
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Тип, видимми дли вмзмванзшеи сторонм, может установитБ дополнителвнме 
ограниченин на возможностб обрагценгш к своим членам. Ниже перечисленм ва- 
риантм ограниченгш доступа к членам типа: 

□ Закрмтми ( приватнми ) д оступ — член типа доступен то лбко длл других членов 
того же типа. 

□ Доступ в семеистве — член типа доступен дли производнмх типов независимо 
от того, принадлежат ли они тои же сборке или нет. Обратите внимание: во мно- 
гих нзмках (таких, как C# и С++) доступ в семеистве обозначаетсл клкзчевмм 
словом protected. 

□ Доступ в семеистве и сборке — член типа доступен д./ш производнмх типов, но 
толбко в том случае, если они определнготсн в тои же сборке. Многие нзмки (на- 
пример, C# и Visual Basic) не поддерживагот зтот уровенБ доступа. Разумеетсл, 
в IL -коде он поддерживаетси. 

□ Доступ в сборке — член типа доступен длн лгобого кода, входнгцего в ту же сбор- 
ку. Во многих нзмках доступ в сборке обозначаетсн клгочевмм словом internal. 

□ Доступ в семеистве или сборке — член типа доступен дли производнмх типов 
из лгобои сборки, а также длл лгобмх типов в тои же сборке. В C# зтот вариант 
доступа обозначаетсн клгочевмми словами protected internal. 

□ Открмтми доступ — член типа доступен д./ш лгобого кода в лгобои сборке. 

Кроме того, CTS определлет правила, управлнгогцие наследованием, работои 
виртуалБнмх методов, сроком жизни обвектов и т. д. Зти правила разрабатмвалисБ 
длн вмраженгш семантики, вмражаемои средствами современнмх нзмков програм- 
мированин. Собственно, вам вообгце не придетсн изучатБ правила CTS как таковме, 
потому что вмбраннми вами нзмк предоставлнет собственнми синтаксис и правила 
работм с типами. Синтаксис конкретного нзмка преобразуетсл в IL, «нзмк» CLR, 
в процессе генерировашш сборки на стадии компилиции. 

Когда л толбко начал работатБ с CLR, доволбно бмстро вмнснилосв, что нзмк 
и поведеиие кода лучше рассматриватБ как две разнБге сугцности. ИсполБзун С++/ 
CLI, вб1 можете определнтБ собственнБге типбг с нужнБш набором членов. Конечно, 
дли определенгш того же типа с теми же членами можно также исполвзоватБ C# 
или Visual Basic. Конечно, синтаксис определенгш типа зависит от ввгбранного 
нзБгка, но поведение типа остаетсл неизменнвш, потому что оно определлетсл 
спецификациеи CTS. 

Что6б1 сказанное стало более поннтнбш, н приведу пример. CTS позволнет типу 
6б1тб производнБш толбко от одного базового класса. И хотн нзбгк С++ поддержи- 
вает возможностб наследовашш от несколвких базовкгх типов, CTS не примет такие 
классвг и не будет работатБ с ними. Обнаружив попвгтку созданин управлиемого 
кода с типом, производнвш от несколБКих базовБгх типов, компилитор Microsoft 
C++/CLI ввгдает сообгцение об ошибке. 
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А вот eine одно правило CTS: все типм должнм 6 мтб производнмми (прнмо 
или опосредованно) от предопределенного типа System.Object (то естБ от типа 
Object из пространства имен System). Тип Ob ject нвлнетсн корнем иерархии типов, 
а следователБно, гарантирует, что каждћш зкземплир типа обладает минималБНБш 
набором аспектов поведенгш. А если говоритв конкретнее, тип System .Object по- 
зволнет сделатв следукицее: 

□ сравнитБ два зкземплнра на равенство; 

□ получитв хеш-код зкземплира; 

□ запроситБ фактическии тип зкземплира; 

□ вбшолнитб поверхностное (поразридное) копирование зкземплира; 

□ получитв строковое представление текугцего состолнгш зкземплнра. 

CLS 

Моделв СОМ позволнет обвектам, написаннБш на разнБ1х нзБшах, взаимодеиство- 
ватв друг с другом. С другои сторонБц среда CLR интегрирует все ц.збпш и обеспе- 
чивает возможностб равноправного исполБЗОванин обБектов, написаннвк на одном 
лзБ1ке, в коде на совершенно другом нзвше. Такаи интеграциц стала возможнои 
благодарн стандартному набору типов CLR, метаданнвш (самодокументиругогцеи 
информациеи о типах) и обгцеи исполнителБнои среде. 

Хотн нзБШОван интеграцгш — совершенно замечателвнан цслб, по правде говорн, 
ИЗБ1КИ программировангш оченв силбно отличаготсл друг от друга. Например, не- 
которнге нзбгки не учиткгвагот регггстр символов в именах, другие не поддерживагот 
целвге числа без знака, перегрузку операторов или методвг с поддержкои перемен- 
ного количества аргументов. 

Если вбг намереваетесБ создаватБ типбг, с которБгми можно легко работатк 
из других нзбгков программированин, вам придетсл исполБЗОватБ толбко те воз- 
можности вашего извгка, которкге заведомо доступнвг во всех осталвнвгх лзБгках. 
Длн упрогценин зтои задачи компангш Microsoft определила спецификациго CLS 
(Common Language Speciication); в неи перечислен минималвнвги набор возмож- 
ностеи, которвге должнбг поддерживатБСн компилнтором дли генерировангш типов, 
совместимБгх с другими компонентами, написаннБгми на других CLS -совместимБгх 
изБгках на базе CLR. 

Возможности CLR/CTS вбгходлт далеко за рамки подмножества, определлемого 
CLS. Если вас не беспокоит межБнзвгковаи совместимоств, вбг можете разрабатБг- 
ватБ тггпбг с широкои функцггоналБностБго, огранггчиваемои толбко возможностлми 
нзБгка. А еслгг говоритБ конкретнее, CLS определлет правила, которвгм должнбг 
соответствоватБ типбг и методБг с внешнеи видимостбго, длн того что6бг онгг моглгг 
исполБЗОватБСн в лгобом CLS -совместимом нзвгке программировангш. Обратите 
внимание: правила CLS не распространнготси на код, доступнБш толбко в опре- 
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делнклцеи сборке. На рис. 1.6 наглндно представленм концепции, вшраженнме 
в зтом абзаце. 



Рис. 1.6. Разние азнки поддержива 1 от подмножество CLR/CTS и надмножество CLS 
(возможно, разнме подмножества) 

Как видно из рис. 1.6, CLR/CTS определнет набор функционалБнмх возмож- 
ностеи. НекоторБ1е нзбжи реализугот более широкое подмножество CLR/CTS. 
Например, программист, пожелавшии работатБ на м.змке ассемблера IL, сможет 
исполБЗОватБ все возможности CLR/CTS. Болбшинство других нзбжов (С#, Visual 
Basic, Fortran и т. д.) предоставлигот в распорнжение программиста подмножество 
возможностеи CLR/CTS. CLS определнет минималБНБп! набор возможностеи, 
которБ 1 е должнб1 поддерживатБСн всеми нзБжами. Если вб1 проектируете тип на 
одном из 1 ) 1 ке и собираетесБ исполБЗОватБ его в другом а.чмке, не размегцаите никакие 
возможности, вБ1ходлгцие за пределБ1 CLS, в его открбггбгх и загцигценнБгх членах. 
В зтом случае членБ1 вашего типа могут статБ недоступнБши дли программистов, 
пишугцих код на других изБжах программировангш. 

В следугогцем коде CLS -совместимБш тип определнетси в коде С#. Однако при 
зтом тип содержит несколБКО CLS-HecoBMecTHMbix конструкции, из-за которБгх 
компилитор C# вБвдает предупрежденгш. 

using System; 

// Приказмваем компилвтору проверлтБ код 
// на совместимостБ с CLS 
[assembly: CLSCompliant(true)] 

namespace SomeLibrary { 

// Предупрежденил вмводвтсАј потому что класс нвллетсв открмтим 
public sealed class SomeLibraryType { 

// Предупреждение : возврацаемии тип 'SomeLibrary.SomeLibraryType.Abc() ’ 

// Не ВВЛВеТСЛ CLS-COBMeCTHMblM 
public UInt 32 Abc() { return 0 ; } 


продолжение & 
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// Предупреждение: идентификаторн ’ SomeLibrary.SomeLibraryType . abc() ', 

// отличакнциесн толико регистром символов, не лвллитсл 
// CLS-coBMecTHMbiMH 
public void abc() { } 

// Предупрежденин нет: закрнтми метод 
private UInt 32 АВС() { return 0 ; } 

} 

} 

В зтом коде атрибут [assembly :CLSCompliant(true) ] применнетсл к сборке. 
Зтот атрибут приказмвает компилнтору следитБ за тем, чтобм тип с открмтмм 
уровнем доступа не содержал конструкции, преплтствуклцих его испо. њзонапи io 
в другом нзмке программировангш. При компилиции зтого кода компилитор C# 
вБвдает два предупрежденип. Первое вмдаетсл из-за того, что метод Abc возврагцает 
целое без знака; некоторме нзмки программировангш не умегот работатБ с беззна- 
ковмми целмми числами. Второе предупреждение вмдаетсл из-за того, что тип 
содержит два открмтмх метода, различагогцихси толгжо регистром и типом воз- 
врагцаемого значенгш: Abc и abc. В Visual Basic и некотормх других нзмках вмзов 
обоих методов невозможен. 

Если удалитБ клгочевое слово public перед sealed class SomeLibraryType 
и перекомпилироватБ код, оба предупрежденгш пропадагот. Дело в том, что тип 
SomeLibraryType по умолчаниго рассматриваетсл как internal, а следователвно, 
становитсл недоступнвш за пределами сборки. Полнбш список правил CLS при- 
веден в разделе «Cross-Language Interoperability» документации .NET Lramework 
SDK (http://msdn.microsoft.com/en-us/library/730f1wy3.aspx). 

Позволвте мне изложитб правила CLS в пределвно упрогценном виде. В CLR 
каждвш член типа нвллетсл либо полем (даннвге), либо методом (поведение). Зто 
означает, что каждвш избгк программировангш должен уметв обрагцатБСп к полнм 
и ББгзБшатБ методБг. НекоторБге полл и некоторнге методБг исполБзуготсл специ- 
алБНБгм образом. Длп упрогценип программированил нзбгки обкгчно предостав- 
лпгот дополнителБНБге абстракцгш, упрогцагогцие реализациго зтих стандартнкгх 
паттернов — перечисленгш, массивБг, своиства, индексаторвг, делегатвг, со6бгтил, 
конструкторБг, финализаторБг, перегрузки операторов, операторвг преобразовангш 
и т. д. Когда компилнтор встречает зти абстракцгш в исходном коде, он должен пре- 
образоватв их в поли и методвг, что6бг сделатБ их доступнБши длн CLR и лго6бгх 
других лзБгков программировангш. 

Следугогцее определение типа содержит конструктор, финализатор, перегру- 
женнвге операторБг, своиство, индексатор и собвгтие. Учтите, что приведеннБш 
код написан всего лишб длн того, что6бг он компилировалсп, и не демонстрирует 
правилБного способа реализацгш типа. 

using System; 


internal sealed class Test { 
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// Конструктор 

public Test() {} 

// Финализатор 

~Test() {} 

// Перегрузка оператора 

public static Boolean operator == (Test tl, Test t2) { 
neturn tnue; 

} 

public static Boolean openaton != (Test tl, Test t2) { 
netunn false; 

} 

// Перегрузка оператора 

public static Test openaton + (Test tl, Test t2) { netunn null; } 

// Своиство 

public Stning APnopenty { 
get { netunn null; } 
set { } 

} 

// Индексатор 

public Stning this[Int32 x] { 
get { netunn null; } 
set { } 

} 

// Собмтие 

public event EventHandlen AnEvent; 

} 

Резулматом компилнции зтого кода ивлиетсл тип, содержагции набор полеи 
и методов. В зтом можно легко убедитћсл, просмотрев полученнми управлиемми 
модулћ в программе IL Disassembler (ILDasm.exe), входнвдеи в пакет ,NET Framework 
SDK (рис. 1.7). 

В табл. 1.4 продемонстрировано соответствие между конструкцтшми нзмка про- 
граммировантш и зквивалентнмми полими/методами CLR. 

Допол|[ 1 пс./њш, 1 Сузлр>1 типа Test, пе viiOManv'i'bie нтабл. 1.4— .class, .custom, 
AnEvent, APropenty и Item, — содержат дополнителБнме метаданнБге типа. Они 
не отображаготсл на поли или методћг, а толбко предоставлнгот дополнителвнуго 
информацшо о типе, которан может исполБЗОватБСи CLR, лзБгками программи- 
ровантш или инструментами. Например, программа может узнатв, что тип Test 
поддерживает собвггие AnEvent, длл работБ1 с которБгм исполБзутотсн два метода 
(add_AnEvent и remove_AnEvent). 
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Глава 1. МоделБ ввшолненил кода в среде CLR 



Рис. 1.7. Программа ILDasm с поллми и методами типа Test 
(информацил получена из метаданнмх) 


Таблица 1.4. Полл и методц! типа Test 


Член типа 

РазновидностБ 

Зквивалентнал конструкцил 
q3biKa программированил 

AnEvent 

Поле 

Собнтие; имл полл - AnEvent, тип - System. 
EventHandler 

.ctor 

Метод 

Конструктор 

Finalize 

Метод 

Финализатор 

add_AnEvent 

Метод 

Метод добавленил обработчика собштил 

get_AProperty 

Метод 

Get -метод доступа своиства 

get_Item 

Метод 

Get -метод индексатора 

op_Addition 

Метод 

Оператор + 

op_Equality 

Метод 

Оператор == 

°p_In e quality 

Метод 

Оператор != 

remove_AnEvent 

Метод 

Метод удаленин обработчика собнтшг 

set_AProperty 

Метод 

Set -метод доступа своиства 

set_Item 

Метод 

Set -метод индексатора 
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Взаимодеиствие с неуправллеммм кодом 

.NET Framework обладает множеством преимугцеств перед другими платформами 
разработки. Впрочем, лишб немногие компании могут позволитб себе заново спро- 
ектироватБ и реализоватБ весћ сугцествугогции код. Компанин Microsoft понимает 
o'i'o, позтому среда CLR бмла спроектирована так, чтобм приложенин могли со- 
стонтб как из управлнеммх, так и из неуправлнеммх компонентов. А если говоритБ 
конкретнее, CLR поддерживает три сценаргш взаимодеиствии: 

Управлнемми код может вмзмватћ неуправлнемме функции из DLL с ис- 
полБЗОванием механизма P/Invoke (сокрагцение от «Platform Invoke»). В конце 
концов, многие типм, определнемме в FCL, во внутреннеи реализации вмзмвагот 
функции, зкспортируемме из Kernel32.dll, User32.dll и т. д. Многие измки програм- 
мировангш предоставлнгот средства, упрогцагогцие вмзов неуправлнеммх функции 
из DLL в управлиемом коде. Например, приложение C# может вмзватБ функциго 
CreateSemaphore, зкспортируемуго библиотекои Kernel32.dll. 

Управлнемми код может исполћзоватБ готовБге компонентБГ СОМ. Многие 
компании уже реализовали болБшое количество неуправлчемБгх компонентов 
СОМ. На основе библиотек типов из зтих компонентов можно создатБ управлие- 
муго сборку с описанием компонента СОМ. УправлнемБш код обрагцаетси к типу 
из управлнемои сборки точно так же, как к лгобому другому управлиемому типу. 
За дополнителБнои информациеи обрагцаитесБ к описаниго программБг Tlblmp.exe, 
входигцеи в поставку .NET Framework SDK. 

Неуправлиемвш код может исполвзоватБ управлнемвга тип. БолБшан частБ 
сугцествугогцего неуправлнемого кода требует наличгш компонента СОМ. Такие 
компонентБг гораздо прогце реализуготсн с управлиемБгм кодом, что позволлет из- 
бежатБ служебного кода, свнзанного с подсчетом ссбшок и интерфеисами. Например, 
на C# можно написатБ злемент управленгш ActiveX или расширение командного 
процессора. За дополнителБнои информациеи обрагцаитесБ к описаниго программ 
TlbExp.exe и RegAsm.exe, входнгцих в поставку .NET Framework SDK. 

ПРИМЕЧАНИЕ 

4to6w помочб разработчикам в написании программ, взаимодеиствукнцих с машин- 
HbiM кодом, компанич Microsoft опубликовала исходнб 1 и код программ Туре Library 
Importer и P/lnvoke Interop Assistant. Зти nporpaMMbi и их исходнбш код можно за- 
грузитБ по адресу http://CLRInterop.CodePlex.com/. 

В Windows 8 компангш Microsoft ввела новбш интерфеис прикладного програм- 
мировангш, назБшаемБш Windows Runtime (WinRT). Его внутреннчч реализацгш 
базируетсн на компонентах СОМ, но вместо библиотеки типов компонентБг СОМ 
описмвагот свои API в стандарте метаданнБгх ЕСМА, созданном рабочеи группои 
.NET Framework. ЗлегантностБ решенгш заклгочаетси в том, что код, написаннБШ 
на изБгке .NET, может (в основном) легко взаимодеиствоватБ с WinRT APL CLR 
обеспечивает все взаимодеиствие с СОМ во внутреннеи реализацгш, вам вообгце 
не придетси исполБЗОватБ дополнителБнме средства — все просто работает! За 
подробностнми обрагцаитесБ к главе 25 . 


Глава 2. Компоновка, 
упаковка, развертнвание 
и администрирование 
приложении и типов 


Прежде чем переити к главам, описмвагогцим разработку программ длн Microsoft 
.NET Framework, даваите обсудим вопросм создании, упаковки и развертмвангш 
приложении и их типов. В зтои главе акцент сделан на основах создангш компонен- 
тов, предназначеннмх исклгочителБно длн ваших приложении. В главе 3 рассказано 
о рнде более сложшлх, но оченБ важнћгх концепции, в том числе способах создангш 
и примененгш сборок, содержагцих компонентБг, предназначеннБге дли исполБЗОва- 
нгш совместно с другими приложенгшми. В зтои и следугогцеи главах также показано, 
как администратор может влгштб на исполненгге приложенгш гг его типов. 

Современнвге приложенгш состонт ггз тггпов, которвге создаготси самггмгг раз- 
работчиками гглгг компанггеи Microsoft. Помимо зтого, процветает целал отраслв 
поставгциков компонентов, которвге исполвзуготси другггмгг компанггнмгг дли уско- 
ренгш разработки проектов. Тггпбг, реализованнБге пргг помогцгг нзнгка, орггентиро- 
ванного на обгцензБгковуго исполнигогцуго среду (CLR), способнвг легко работатк 
друг с другом; пргг зтом базовнги класс такого тггпа может 6 бгтб написан на другом 
нзБгке программированггн. 

В зтои главе обБисннетси, как зти типбг создаготсн гг упаковБгваготсл в фаилвг, 
предназначеннБге длн развертБгванин. В процессе изложении даетсн краткии ггсто- 
рическгги обзор некоторвгх проблем, решеннвгх с приходом .NET Framework. 


Задачи развертнванил в .NET Framework 

Все годбг своего сугцествовангш операционнаи система Windows «славиласБ» не- 
стабгглБностБго и чрезмернои сложностбго. Такаи репутацил, заслуженнаи гглгг нет, 
сложиласБ по рнду прггчггн. Во-первБгх, все приложенгги исполвзугот динамическгг 
подклгочаемБге библиотеки (Dynamic Link Library, DLL), созданнвге Microsoft 
гг другими проггзводггтелимгг. Посколвку приложение ггсполниет код, написаннБги 
разнБгмгг производителлми, нгг одггн разработчик какои-либо частгг программвг не 
может 6бгтб на 100 % уверен в том, что точно знает, как друггге собираготсч применнтБ 
созданнБги ггм код. В теоргги такал сггтуацгги чревата лгобвгми неполадкамгг, но на 
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практике взаимодеиствие кодов от разнмх производителеи редко создает проблемм, 
так как перед развертмванием приложении тестиругот и отлаживагот. 

Однако полБЗОватели часто сталкиваготсп с проблемами, когда производителБ 
решает обновитБ поставленнуго им программу и предоставлнет новбш фаилБк Пред- 
полагаетсл, что новбго фаилБг обеспечивагот «обратнуго совместимоств» с прежним 
программшлм обеспечением, но кто за зто поручитсл? Одному производителго, 
ввшускагогцему обновление своеи программвг, фактически не под силу заново 
протестироватв и отладитБ все сугцествугогцие приложенгш, чтобвг убедитвсл, что 
измененгш при обновлении не влекут за собои нежелателвнБгх последствии. 

Уверен, что каждвги читагогции зту книгу сталкивалсн с тои или инои разновид- 
ностбго проблемБг, когда после установки нового приложенгш нарушаласв работа 
однои (или несколБКих) из установленнБгх ранее программ. Зта проблема, наво- 
дигцан ужас на рндоввгх полБЗОвателеи компвготеров, получила название <<кошмар 
DLL». В конечном итоге полвзователи должнбг как следует обдуматк, стоит ли 
устанавливатБ новое программное обеспечение на их компБготерБк Лично н вообгце 
отказалси от установки некоторвгх приложении из опасенгш, что они нанесут вред 
наиболее важнвш дли менн программам. 

Второи фактор, повлгшвшии на репутациго Windows, — сложности при установке 
приложении. Болбшинство приложении при установке умудрнготсн <<просочитБСн» 
во все части операционнои системвг. Например, при установке приложенгш проис- 
ходит копирование фаилов в разнвге каталоги, модификацгш параметров реестра, 
установка нрлвгков и ссбшок на рабочии стол (Desktop), в менго Пуск (Start) и на 
панелв бБгстрого запуска. Проблема в том, что приложение — зто не одиночнан изо- 
лированнал сугцноств. НелБЗн легко и просто создатк резервнуго копиго приложенгш, 
посколвку, кроме фаилов приложенин, придетсл скопироватБ соответствугогцие 
части реестра. Вдобавок, нелвзи просто взнтб и переместитБ приложение с однои 
машинБг на другуго — длн зтого нужно запуститБ программу установки егце раз, что- 
6 бг корректно скопироватБ все фаилвг и параметрБг реестра. Наконец, приложение 
не всегда просто удалитв — нередко ввшсниетсл, что какан-то его частв притаиласБ 
где-то внутри компвготера. 

Третии фактор — безопасностБ. При установке приложении записБгваетсл 
множество фаилов, созданнвгх самБши разнБши компангшми. Вдобавок, многие 
веб-приложенгш (например, ActiveX) зачастуго содержат программнвш код, ко- 
торБш сам загружаетси из Интернета, о чем полБзователи даже не подозревагот. 
На современном уровне технологгш такои код может вбшолннтб лгобБге деиствгш, 
вклгочан удаление фаилов и рассвшку злектроннои почтбг. ПолБЗОватели справед- 
ливо опасаготсл устанавливатБ новБге пргшоженгш из-за угрозпг потенциалБного 
вреда, которвш может 6 бгтб нанесен их компБготерам. Длн того что6бг полБЗОватели 
чувствовали себн спокоинее, в системе должнбг 6бгтб встроеннБге функцгш загцитБг, 
позволнгогцие ивно разрешатв или запрегцатБ доступ к системнкш ресурсам коду, 
созданному теми или инбши компангшми. 

Как показано в зтои и следугогцеи главах, платформа .NET Framework в зна- 
чителБнои мере устраниет <<кошмар DLL» и делает сугцественнБги шаг вперед 
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Глава 2. Компоновка, упаковка, развер™вание и администрирование приложении 


к решешпо проблемм, свнзаннои с распределением даннмх приложенин по всеи 
операционнои системе. Например, в отличие от модели СОМ информацшо о ком- 
понентах уже не нужно сохранитБ в реестре. К сожаленшо, приложенинм пока еше 
требуготсн ссбшки и лрлБпеи. Совершенствование системБ1 зашитБ1 свнзано с новои 
моделвго безопасности платформБ1 .NET Framework — безопасностнт доступа на 
уровне кода (code access security). Если безопасностБ системБ1 Windows основана на 
идентификации полвзователл, то безопасноств доступа на уровне кода основана на 
правах, которвге контролируготси хостом приложении, загружагогцим компонентБ 1 . 
Сетевое приложение (такое, как Microsoft SQL Server) может предоставитв коду 
минималБНБге полномочгш, в то времи как локалвно установленное приложение во 
времн своего ввшолнешш может иметБ уровенБ полного довергш (со всеми полно- 
мочинми). Как видите, платформа .NET Framework предоставллет полвзователлм 
намного болвше возможностеи по контролго над тем, что устанавливаетсл и bbi- 
полниетсн на их машинах, чем когда-либо давала им система Windows. 


Компоновка ТИПОВ В МОДУЛБ 

В зтом разделе рассказБ1ваетсл, как превратитв фаил, содержагции исходнбш код 
с разнБши типами, в фаил, пригоднБП! дли развертБшангш. Дли начала рассмотрим 
следуклцее простое приложение: 

public sealed class Program { 
public static void Main() { 

System.Console.WriteLine("Hi"); 

} 

} 

ЗдесБ определен тип Program c единственнБш статическим otkpkitkim методом 
Main. Внутри метода Main находитсл ссншка на другои тип — System . Console. 
Зтот тип разработан в компании Microsoft, и его программнБпг код на изш<е IL, 
реализугогции его методБц находитсн в фаиле MSCorLib.dll. Таким образом, данное 
приложение определлет собственнвш тип, а также исполБзует тип, созданнБш 
другои компаниеи. 

Длн того что6б1 построитБ зто приложение, сохраните зтот код в фаиле (допу- 
стим, Program.es, а затем наберите в команднои строке следугогцее: 

csc.exe /out:Program.exe /t:exe /r:MSCorLib.dll Program.es 

Зта команда приказвшает компилитору C# создатк исполннемБп! фаил Program. 
ехе (ими задано параметром /out: Program.exe). Тип создаваемого фаила — кон- 
солвное приложение Win32 (тип задан параметром /t[arget] :ехе). 

При обработке фаила с исходнбш кодом компиллтор C# обнаруживает ссбш- 
ку на метод WriteLine типа System.Console. На зтом зтапе компилитор должен 
убедитБСл, что зтот тип сугцествует и у него еств метод WriteLine. Компшштор 
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также провернет, чтобм тппм аргументов, предоставлнеммх программои, совпадали 
с ожидаеммми типами метода WriteLine. ПосколБку тип не определен в исходном 
коде на С#, компилитору C# необходимо передатБ набор сборок, которБШ позво- 
ллт ему разрешитБ все ссбшки на внешние типбг В показаннои команде параметр 
/ n [ eference ]: MSCorLib. dll приказБшает компилнтору вести поиск внешних типов 
в сборке, идентифицируемои фаилом MSCorLib.dll. 

MSCorLib.dll — специалБНБш фаил, в котором находлтсл все основнбш типбк 
Byte, Char, String, Int32 и т. д. В деиствителБности, зти типбг исполБзуготсл так 
часто, что компилитор C# обрагцаетсл к зтои сборке (MSCorLib.dll) автоматически. 
Другими словами, следугогцан команда (в неи опугцен параметр /г) даст тот же 
резулвтат, что и предБвдушал: 
csc.exe /out : Program. ехе /t:exe Program.es 

Более того, посколбку значенил, заданнБге параметрами команднои строки 
/out : Program . ехе и /t : ехе, совпадагот со значенинми по умолчаниго, следугогцап 
команда даст аналогичнБ 1 и резулвтат: 

csc.exe Program.es 

Если по какои-то причине bki не хотите, что6б1 компиллтор C# обрагцалсл 
к сборке MSCorLib.dll, исполБзуите параметр /nostdlib. В компании Microsoft зтот 
параметр исполБзуетсл при построении сборки MSCorLib.dll. Например, во времн 
исполненгш следугогцеи командБ1 при компилиции фаила Program.es генерируетсн 
ошибка, посколвку тип System.Console определен в сборке MSCorLib.dll: 

csc.exe /out : Program. ехе /t:exe /nostdlib Program.es 

А теперБ присмотримсн поближе к фаилу Program.exe, созданному компшштором 
С#. Что он из себн представлиет? Длл начала зто стандартнвги фаил в формате РЕ 
(portable executable). Зто значит, что машина, работагогцан под управлением 32- или 
64-разриднои версии Windows, способна загрузитв зтот фаил и что-нибудБ с ним 
сделатБ. Система Windows поддерживает два типа приложении: с консолбнбши 
(Console User Interface, CUI) и графическими полБЗОвателБСКими интерфеисами 
(Graphical User Interface, GUI). Параметр /t: ехе указБшает компилнтору C# создатБ 
консолБное приложение. Длп создании приложенгш с графическим интерфеисом 
необходимо указатБ параметр /t :winexe, а длл создашш приложенгш Windows 
Store - параметр /t : appcontainerexe. 


Фаил параметров 

В завершение рассказа о параметрах компилнтора хотелосв 6bi сказатБ несколБко 
слов о фаплах параметров (response files) — текстовБгх фаилах, содержаших набор 
параметров команднои строки длл компилнтора. При вБшолнении компилнтора CSC. 
ехе открБшаетсн фаил параметров и исполБзуготсн все указаннБге в нем параметрБц 
как если 6bi они 6бши переданБ! в составе команднои строки. Фаил параметров 
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передаетсл компилнтору путем указании его в команднои строке с префиксом 
Например, пустБ естБ фаил параметров MyProject.rsp со следуклцим текстом: 

/out :МуРгој ect .ехе 
/target:winexe 

Длн того чтобвг компилнтор (CSC.exe) исполБЗОвал зти параметрвг, необходимо 
ввгзватБ фаил следукзгцим образом: 

csc.exe @MyProject.rsp CodeFilel.es CodeFile 2 .cs 

Зта строка сообгцает компилнтору C# имн вбгходного фаила и тип скомпили- 
рованнои программБг. Очевидно, что фаилвг параметров исклгочителвно полезнБг, 
так как избавлнгот от необходимости вручнуго вводитб все аргументвг команднои 
строки каждБги раз при компилнции проекта. 

Компилитор C# допускает исполБЗОвание несколвких фаилов параметров. По- 
мимо нвно указаннвгх в команднои строке фаилов, компилнтор автоматически игцет 
фаил с именем CSC.rsp в текугцем каталоге. Компилнтор также провериет каталог 
с фаилом CSC.exe на наличие глобалвного фаила параметров CSC.rsp, в котором 
следует указвшатв параметрБг, относигциесл ко всем проектам. В процессе своеи 
работвг компилнтор обБединнет параметрнг из всех фаилов и исполвзует их. В случае 
конфликта параметров в глобалвнБгх и локалБНБгх фаилах предпочтение отдаетсн 
последним. Кроме того, лгобнге нвно заданнвге в команднои строке параметрвг имегот 
более вбгсокии приоритет, чем указаннкге в локалвнБгх фаилах параметров. 

При установке платформвг .NET Framework по умолчаншо глобалБНБш фаил 
СЗС.гзрустанавливаетслв каталог %SystemRoot%\Microsoft .NET\Framework(64)\ 
уХ.Х.Х (где Х.Х.Х — версил устанавливаемои платформвг ,NET Framework). 
Новеишан версин зтого фаила содержит следугогцие параметрвг: 

# Зтот фаил содержит параметрм команднои строки, 

# которие компиллтор C# команднои строки (CSC) 

# будет обрабатмватБ в каждом сеансе компиллции, 

# если толцко не задан параметр "/noconfig". 

# Сшлки на стандартнме библиотеки Framework 
/г: Accessibility . dll 

/г: Microsoft.CSharp.dll 

/г: System.Configuration . dll 

/г :System.Configuration .Install.dll 

/г: System.Core.dll 

/г: System.Data.dll 

/г :System.Data.DataSetExtensions.dll 

/r:System.Data. Linq.dll 

/г :System.Data.OracleClient.dll 

/г :System.Deployment.dll 

/г: System.Design.dll 

/г :System.DirectoryServices.dll 

/r:System.dll 

/г :System.Drawing.Design.dll 
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/г: System.Drawing.dll 

/г: System.EnterpriseServices.dll 

/г: System.Management . dll 

/г: System.Messaging.dll 

/г: System.Runtime.Remoting.dll 

/г: System.Runtime.Serialization.dll 

/г: System.Runtime.Serialization . Formatters.Soap.dll 

/г: System.Security.dll 

/г: System.ServiceModel . dll 

/г :System.ServiceModel .Web.dll 

/г :System.ServiceProcess.dll 

/г : System.Transactions.dll 

/r:System. Web.dll 

/г : System.Web.Extensions.Design.dll 

/г : System.Web.Extensions.dll 

/г: System.Web.Mobile.dll 

/г: System.Web.RegularExpressions. dll 

/г :System.Web.Services. dll 

/г :System.Windows.Forms. Dll 

/г :System.Workflow.Activities.dll 

/г : System.Workflow.ComponentModel.dll 

/г : System.Workflow.Runtime.dll 

/r:System. Xml.dll 

/г :System.Xml .Linq.dll 

B глобалћном фаиле CSC.rsp естБ ссмлки на все перечисленнме сборки, позто- 
му нет необходимости указмватБ их нвно с iiomoihiiIo параметра /reference. Зтот 
фаил параметров исклгочителвно удобен длл разработчиков, так как позволиет 
исполћзоватБ все типбг и пространства имен, определеннвге в различнвгх опубли- 
кованнБгх компаниеи Microsoft сборках, не указншан их все нвно с применением 
параметра /reference. 

Ссбшки на все зти сборки могут немного замедлитв работу компилитора, но 
если в исходном коде нет ссбшок на типбг или членБг зтих сборок, зто никак не 
сказБгваетсн ни на резулвтиругогцем фаиле сборки, ни на производителБности его 
вБшолненгш. 

ПРИМЕЧАНИЕ 

При исполБЗОвании параметра /reference длл ссбшки на какукз-либо сборку мож- 
но указатБ полнни путБ к конкретному фаилу. Однако если такои путБ не указатБ, 
компиллтор будет искатБ нужнБш фаил в следукмдих местах (в указанном порлдке). 

Рабочии каталог. 

Каталог, содержагции фаил самого компиллтора (CSC.exe). Библиотека MSCorLib. 
dll всегда извлекаетсл из зтого каталога. Пуљ к нему имеет примерно следукздии 
вид: 

- %SystemRoot%\Microsoft.NET\Framework\v4.0. #####. 

- Все каталоги, указанние с исполБЗОванием параметра /lib компиллтора. 

- Все каталоги, указанние в переменнои окруженил LIB. 
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Конечно, вм вправе добавлитБ собственнме параметрм в глобалБнми фаил CSC. 
rsp, но зто силбно усложннет репликацшо средм компоновки на разнмх машинах — 
приходитсн помнитб про обновление фаила CSC.rsp на всех машинах, исполБзуеммх 
длн сборки приложении. Можно также датБ компилитору команду игнорироватБ 
как локалБНБш, так и глобалБНБ 1 и фашш CSC.rsp, указав в команднои строке па- 
раметр /noconfig. 


НесколБко слов о метаданнмх 

Что же именно находитсл в фаиле Program.exe? УправлиемБш РЕ-фаил состоит 
из 4-х частеи: заголовка РЕ32(+), заголовка CLR, метаданнБ 1 х и кода на промежу- 
точном изш(с (intermediate language, IL). Заголовок РЕ32(+) хранит стандартнуго 
информациго, ожидаемуго Windows. Заголовок CLR — ото неболвшои блок ин- 
формации, специфичнои длн модулеи, требукзгцих CLR (управлиемБ 1 х модулеи). 
В него входит старшии и младшии номера версии CLR, длл которои скомпонован 
модулБ, рнд флагов и маркер MethodDef (о нем — чутБ позже), указБшаклции метод 
точки входа в модулв, если зто исполннемБш фаил СШ, GUI или Windows Store, 
а также необлзателБнуго сигнатуру строгого имени (она рассмотрена в главе 3). 
Наконец, заголовок содержит размер и смегцение некоторвгх таблиц метаданнвгх, 
расположеннБ 1 х в модуле. Длн того что6б1 узнатБ точнбш формат заголовка CLR, 
изучите структуру IMAGE_COR20_HEADE R > определеннуго в фаиле CorHdr.h. 

МетаданнБге — зто блок двоичнбгх даннБ 1 х, состолгции из несколБКих таблиц. 
Сугцествугот три категоргш таблиц: определении, ссбшок и манифестов. В табл. 2.1 
приводитсн описание некоторвгх наиболее распространеннБ1х таблиц определенгш, 
сугцествугогцих в блоке метаданнвгх модули. 


Таблица 2.1. Основнне таблицБ! определении в метаданнБ 1 х 


Имл ТаблИЦБ! 
определении 

Описание 

ModuleDef 

Всегда содержит одну записв, идентифицирукнцуго модулБ. ЗаписБ 
вклгочает имл фаила модулл с расширением (без указанил пути к фаи- 
лу) и идентификатор версии модулл (в виде сгенерированного компи- 
ллтором кода GUID). Зто позволлет переименоввгватБ фаил, не тернн 
сведении о его исходном имени. Однако настонтелвно рекомендуетсл 
не переименовБгватБ фаил, иначе среда CLR может не наити сборку во 
времл вБшолненил 

TypeDef 

Содержит по однои записи длл каждого типа, определенного в модуле. 
Каждан записв вклгочает имл типа, базовБхи тип, флаги сборки (public, 
private и т. д.) и указкшает на записи таблиц MethodDef, PropertyDef 
и EventDef, содержагцие соответственно сведенил о методах, своиствах 
и со6б1тилх зтого типа 
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Имл таблицш 
определении 

Описание 

MethodDef 

Содержит по однои записи длл каждого метода, определенного в моду- 
ле. Каждан строка вклгочает имл метода, флаги (private, public, virtual, 
abstract, static, final и т. д.), сигнатуру и смегцение в модуле, по которо- 
му находитсн соответствугондии IL -код. Каждал записБ также может 
ссвшатБсл на записБ в таблице ParamDef, где храннтсн дополнителв- 
нБге сведенин о параметрах метода 

FieldDef 

Содержит по однои записи длл каждого полл, определенного в моду- 
ле. Каждан записв состоит из флагов (например, private, public и т. д.) 
и типа полл 

ParamDef 

Содержит по однои записи длл каждого параметра, определенного 
в модуле. Каждан записв состоит из флагов (in, out, retval и т. д.), 
типа и имени 

PropertyDef 

Содержит по однои записи длл каждого своиства, определенного в мо- 
дуле. Каждаи записв вклгочает имл, флаги, тип и вспомогателБное поле 
(оно может 6Б1ТБ ПуСТБ1М) 

EventDef 

Содержит по однои записи длл каждого со6б1тил, определенного в мо- 
дуле. Каждаи записв вклгочает имл и флаги 


Длл каждои сутцности, определиемои в компилируемом исходном тексте, ком- 
пилитор генерирует строку в однои из таблиц, перечисленнмх в табл. 2.1. В ходе 
компилнции исходного текста компилнтор также обнаруживает типм, полн, методм, 
своиства и собмтин, на которме имеготсл ссмлки в исходном тексте. Все сведенин 
о наиденнмх сугцностлх регистрируготсл в несколћких таблицах ссмлок, состав- 
лнгогцих метаданнме. В табл. 2.2 показанм некоторме наиболее распространеннме 
таблицм ссмлок, которме входлт в состав метаданнмх. 


Таблица 2.2. Обидие таблицн ccbmoK, входлидие в метаданнне 


Имл таблицш 

ccbmoK 

Описание 

AssemblyRef 

Содержит по однои записи длл каждои сборки, на которуго ссвша- 
етсн модулБ. Каждал записБ вклгочает сведенил, необходимБШ длл 
привлзки к сборке: ее имл (без указанил расширенил и пути), номер 
версии, регионалБНБге стандартБ1 и маркер открБгтого клгоча (о6бшно 
зто неболБшои хеш-код, созданнБги на основе открвгтого клгоча из- 
дателл и идентифициругогции издателл сборки, на которуго ссвшаетсл 
модулБ). Каждан записБ также содержит несколкко флагов и хеш-код, 
которБги должен служитв контролБнои суммои битов сборки. Среда 

CLR полностбго игнорирует зтот хеш-код и, веролтно, будет игнориро- 
ватв его в будугцем 


продолжение # 
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Таблица 2.2 (продолжение) 


Имл ТаблИЦБ! 

ccbmoK 

Описание 

ModuleRef 

Содержит по однои записи длл каждого РЕ-модулл, реализугошего 
типб1, на которБге он ссвшаетсл. Каждал записв вклгочает имл фаила 
сборки и его расширение (без указашш пути). Зта таблица служит 
длл привлзки модулл вБ13Б1вагошеи сборки к типам, реализованнвш 
в других модуллх 

TypeRef 

Содержит по однои записи длл каждого типа, на которБги ссБшаетсн 
модулБ. Каждап записБ вклгочает имл типа и ссБшку, по которои можно 
его наити. Если зтот тип реализован внутри другого типа, записБ со- 
держит ссБшку на соответствуготцуго записБ таблицБ! TypeRef. Если 
тип реализован в том же модуле, приводитсл ссвшка на записБ табли- 
цб1 ModuleDef. Если тип реализован в другом модуле вБ13Б1ваготцеи 
сборки, приводитсл ссвшка на записк таблицБ! ModuleRef. Если тип 
реализован в другои сборке, приводитсн ссБшка на записБ в таблице 
AssemblyRef 

MemberRef 

Содержит по однои записи длл каждого члена типа (полл, метода, 
а также своиства или метода со 6 бгош), на которБП! ссБшаетсл модулБ. 
Каждан записБ вклгочает имл и сигнатуру члена и указвшает на записБ 
таблицБ 1 TypeRef, содержагцуго сведенил о типе, определлгонџш зтот 
член 


На самом деле таблиц метаданнБ 1 х намного болБше, чем показано в табл. 2.1 
и 2.2; л просто хотел датБ обш,ее представление об информации, исполвзуемои ком- 
пиллтором дли создании метаданнБ 1 х. Ранее уже упоминалосБ о том, что в состав 
метаданнБ1х входлт также таблицБ1 манифестов. О них mbi поговорим чутв позже. 

МетаданнБге управлиемого РЕ-фаила можно изучатв при помош,и различнБ 1 х 
инструментов. Лично л предпочитаго ILDasm.exe — дизассемблер изБ 1 ка IL. Длл 
того что6б1 увидетБ содержимое таблиц метаданнБ1х, вБ1полните следугошуго ко- 
манду: 

ILDasm Program.exe 

Запуститсл фаил ILDasm.exe и загрузитсл сборка Program.exe. Длл того 
что6бг вБгвести метаданнвге в удобочитаемом виде, ввгберите в менго команду 
View ► Metalnfo ► Show! (или нажмите клавиши Ctrl+M). В резулвтате поивитсл 
следугошан информацин: 


ScopeName : Program.exe 

MVID : {CA73FFE80D424610A8D39276195C35AA} 


Global functions 
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Global fields 


Global MemberRefs 


TypeDef #1 (02000002) 

TypDefName: Program (02000002) 

Flags : [Public] [AutoLayout] [Class] [Sealed] [AnsiClass] 
[BeforeFieldlnit] (00100101) 

Extends : 01000001 [TypeRef] System.Object 
Method #1 (06000001) [ENTRYPOINT] 

MethodName: Main (06000001) 

Flags : [Public] [Static] [HideBySig] [ReuseSlot] (00000096) 

RVA : 0x00002050 

ImplFlags : [IL] [Managed] (00000000) 

CallCnvntn: [DEFAULT] 

ReturnType: Void 
No arguments. 

Method #2 (06000002) 

MethodName: .ctor (06000002) 

Flags : [Public] [HideBySig] [ReuseSlot] [SpecialName] 

[RTSpecialName] [.ctor] (00001886) 

RVA : 0Х0000205С 

ImplFlags : [IL] [Managed] (00000000) 

CallCnvntn: [DEFAULT] 
hasThis 

ReturnType: Void 
No arguments. 

TypeRef #1 (01000001) 

Token: 0x01000001 

ResolutionScope: 0x23000001 

TypeRefName: System.Object 

MemberRef #1 (0a@00004) 

Member: (0a000004) .ctor: 

CallCnvntn: [DEFAULT] 
hasThis 

ReturnType: Void 
No arguments. 

TypeRef #2 (01000002) 

Token: 0x01000002 

ResolutionScope: 0x23000001 


продолжение # 
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TypeRefName : System.Runtime.CompilerServices . CompilationRelaxationsAttribute 

MemberRef #1 (0a000001) 

Member: (0a00@001) .ctor: 

CallCnvntn: [DEFAULT] 
hasThis 

ReturnType: Void 
1 Arguments 

Argument #1: 14 

TypeRef #3 (01000003) 

Token: 0x01000003 

ResolutionScope: 0x23000001 

TypeRefName: System.Runtime.CompilerServices.RuntimeCompatibilityAttribute 

MemberRef #1 (0a@00@02) 

Member: (0a00@002) .ctor: 

CallCnvntn: [DEFAULT] 
hasThis 

ReturnType: Void 
No arguments. 

TypeRef #4 (01000004) 

Token: 0x01000004 

ResolutionScope: 0x23000001 

TypeRefName: System.Console 

MemberRef #1 (0a@00@03) 

Member: (0a00@003) UlriteLine: 

CallCnvntn: [DEFAULT] 

ReturnType: Void 
1 Arguments 

Argument #1: String 


Assembly 

Token: 0x20000001 
Name : Program 
Public Кеу : 

Hash Algorithm : 0x00008004 
Version: 0.0.0.0 
Major Version: 0x00000000 
Minor Version: 0x00000000 
Build Number: 0x00000000 
Revision Number: 0x00000000 
Locale: <null> 

Flags : [none] (00000000) 
CustomAttribute #1 (0C000001) 

CustomAttribute Туре: 0a0@0001 
CustomAttributeName: 
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System.Runtime.CompilerServices . CompilationRelaxationsAttribute :: 
instance void .ctor(int32) 

Length: 8 

Value : 01 00 08 00 00 00 00 00 > < 

ctor args: (8) 

CustomAttribute #2 (0C000002) 

CustomAttribute Туре: 0a000002 
CustomAttributeName: 

System.Runtime.CompilerServices.RuntimeCompatibilityAttribute :: 
instance void .ctor() 

Length: 30 

Value : 01 00 01 00 54 02 16 57 72 61 70 4e 6f 6e 45 78 > T WrapNonEx< 

: 63 65 70 74 69 6f 6e 54 68 72 6f 77 73 01 >ceptionThrows < 

ctor args: () 

AssemblyRef #1 (23000001) 

Token: 0x23000001 

Public Кеу or Token: b7 7a 5c 56 19 34 e0 89 

Name: mscorlib 

Version: 4.0.0.0 

Major Version: 0x00000004 

Minor Version: 0x00000000 

Build Number: 0x00000000 

Revision Number: 0x00000000 

Locale: <null> 

HashValue Blob: 

Flags: [none] (00000000) 

User Strings 

70000001 : ( 2) L"Hi" 

Coff symbol name overhead: 0 


K счастБЈО, ILDasm самостоителБно обрабатБ 1 вает таблицБ 1 метаданнБ 1 х и ком- 
бинирует информациго, позтому полБЗОвателго не приходитсл заниматвси синтак- 
сическим разбором низкоуровневБ1Х табличнБ1х даннБ1х. Например, в приведенном 
фрагменте видно, что, показвшаи строку таблицБ 1 TypeDef, ILDasm вбшодит перед 
первои записБнз таблицБ 1 TypeRef определение соответствуклцего члена. 

Не облзателБно пониматн, что означает каждал строка зтого дампа — важно 
запомнитв, что Program.exe содержит в таблице TypeDef описание типа Program. 
Зтот тип идентифицирует открвгтвги запечатаннБш (sealed) класс, производнБги 
от System.Object (то естБ зто ссБшка на типиз другои сборки). Тип Program также 
определнет два метода: Main и . ctor (конструктор). 
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Метод Main — зто статическии открмтми метод, чеи программнми код пред- 
ставлен на нзмке IL (а не в машиннмх кодах процессора, например х86). Main 
возврагцает void и не получает аргументов. Метод-конструктор (всегда отобража- 
емми под именем . cton) ивлнетсл открмтмм, его код также записан на измке IL. 
Тип возврагцаемого значентш конструктора — void, у него нет аргументов, но естБ 
указателБ this, ссБшагогциисл на областн памлти, в которои должен создаватвси 
зкземплнр обвекта при вБ130ве конструктора. 

Л настонтелБно рекомендуго вам позкспериментироватБ с дизассемблером 
ILDasm. Он предоставллет массу полезнБ 1 х сведении, и чем лучше bbi в них раз- 
беретесв, тем бБКтрее изучите обгцензБШОвуго исполннгогцуго среду CLR и ее воз- 
можности. В зтои книге егце не раз будет исполБЗОватБСл дизассемблер ILDasm. 

Просто длл интереса посмотрим на некоторуго статистику сборки Program.exe. 
ВБгбрав в менго программв! ILDasm команду View ► Statistics, увидим следугогцее: 


File size 
РЕ header size 
РЕ additional info 
Num.of PE sections 
CLR header size 
CLR metadata size 
CLR additional info 
CLR method headers 
Managed code 
Data 

Unaccounted 


3584 


512 (496 used) 

(14.29%) 

1411 

(39.37%) 

3 


72 

( 2.01%) 

612 

(17.08%) 

0 

( 0.00%) 

2 

( 0.06%) 

20 

( 0.56%) 

2048 

(57.14%) 

1093 

(30.50%) 


Num.of PE sections : 3 
.text 1024 

.rsrc 1536 

.reloc 512 


CLR metadata size : 612 


Module 

1 

(10 

bytes) 

TypeDef 

2 

(28 

bytes) 

TypeRef 

4 

(24 

bytes) 

MethodDef 

2 

(28 

bytes) 

MemberRef 

4 

(24 

bytes) 

CustomAttribute 

2 

(12 

bytes) 

Assembly 

1 

(22 

bytes) 

AssemblyRef 

1 

(20 

bytes) 

Strings 

184 

bytes 

Blobs 

68 

bytes 

UserStrings 

8 

bytes 

Guids 

16 

bytes 

Uncategorized 

168 

bytes 


0 interfaces, 0 explicit layout 
0 abstract, 0 native, 2 bodies 


CLR method headers : 2 
Num.of method bodies 2 

Num.of fat headers 0 
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Num.of tiny headers 2 

Managed code : 20 
Ave method size 10 

ЗдесБ приводлтси как размерш самого фаила (в баитах), так и размерш его 
составликицих частеи (в баитах и процентах от размера фаила). Приложение 
Program.es оченћ маленБКое, позтому болБшан частБ его фаила занита заголовком 
РЕ и метаданншми. Фактически IL -код занимает всего 20 баит. Конечно, чем болглпс 
размер приложенин, тем чагце типш и ссшлки на другие типш и сборки испо. њзу- 
готсл повторно, позтому размерш метаданншх и данншх заголовка сугцественно 
уменБшаготси по отношениго к обгцему размеру фаила. 

ПРИМЕЧАНИЕ 

В ILDasm.exe ecib ошибка, искажакшдаа отображаемукз информацикз о размере 
фаила. В частности, нелиза довераљ сведениам в строке Unaccounted. 


Обвединение модулеи 
длл созданил сборки 

Фаил Program.exe — зто не просто РЕ-фаил с метаданншми, аеше и сборка (assembly), 
то естБ совокупностБ одного или несколћких фаилов с определенгшми типов и фаи- 
лов ресурсов. Один из фаилов сборки вшбираетсн длн храненгш ее манифеста. Ма- 
нифест (manifest) — зто егце один набор таблиц метаданншх, которше в основном 
содержат имена фаилов, составлнгогцих сборку. Кроме того, зти таблицш описшвагот 
версиго и регионалБнше стандартш сборки, ее издателн, обгцедоступнше зкспорти- 
руемше типш, а также все составлигогцие сборку фаилш. 

CLR работает со сборками, то естп сначала CLR всегда загружает фаил с та- 
блицами метаданншх манифеста, а затем получает из манифеста имена осталћншх 
фаилов сборки. Некоторше характеристики сборки стоит запомнитш 

□ в сборке определенш многократно исполћзуемше типш; 

□ сборке назначаетсл номер версии; 

□ со сборкои может бппп свизана информацгш безопасности. 

У отделБншх фаилов сборки, кроме фаила с таблицами метаданншх манифеста, 
таких атрибутов нет. 

Чтобш упаковатБ типш, а также обеспечитБ безопасностБ типов и управление 
их версгшми, нужно поместитБ типбг в модули, обБединеннБге в сборку. Чагце всего 
сборка состоит из одного фаила, как приложение Program.exe в рассмотренном при- 
мере, но могут 6бгтб и сборки из несколБКих фаилов: РЕ-фаилов с метаданнБгми 
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и фаилов ресурсов, например GIF- или JPG -фаилов. Р1аверное, пронде представлнтБ 
себе сборку как «логическии» ЕХЕ- или DLL -фаил. 

Уверен, многим читателлм интересно, зачем компании Microsoft понадобилосБ 
вводитб новое понитие — «сборка». Дело в том, что сборка позволнет разграничитБ 
логическое и физическое поннтил многократно исполБзуеммх типов. Допустим, 
сборка состоит из несколг>ких типов. При зтом типм, применнемме чагце всех, 
можно поместитБ в один фаил, а применнемБге реже — в другои. Если сборка раз- 
вертвшаетсл путем загрузки через Интернет, клиент может вовсе не загружатв фаил 
с редко исполБзуемБши типами, если он никогда их не задеиствует. Например, 
независимвш поставшик ПО (independent software vendor, ISV), специализирук)- 
гцииси на разработке злементов управленин полБЗОвателвского интерфеиса, может 
реализоватБ в отделвном модуле типбг Active Accessibility (необходимБге длл со- 
ответствин требованиим логотипа Microsoft). Загружатв зтот модулБ достаточно 
лишб тем, кому нужнБ1 специалБНБге возможности. 

Можно настроитв приложение так, что6бг оно загружало фаилБ 1 сборки, опреде- 
лив в его конфигурационномфаиле алемент codeBase (см. подробнее главу 3). Зтот 
злемент идентифицирует URL -адрес, по которому можно наити все фаилБ 1 сборки. 
При попБгтке загрузитБ фаил сборки CLR получает URL из злемента codeBase 
и провернет наличие нужного фаила в локалвном кзше загруженннгх фаилов. Если 
фаил там присутствует, то он загружаетсн, если нет — CLR исполвзует длн загрузки 
фаила в кзш URL -адрес. Если наити нужнвги фаил не удаетсл, CLR генерирует ис- 
клгочение FileNotFoundException. 

У менн еств три аргумента в полвзу примененил многофаиловБгх сборок. 

□ Можно распределитБ типбг по несколБКим фаилам, допускаи избирателБнуго 
загрузку необходимБгх фаилов из Интернета, а также частично упаковвшатБ 
и развертБшатБ типбц варБируи функционалБностБ приложенин. 

□ Можно добавлитБ к сборке фаи./њ 1 с ресурсами и даннкши. Допустим, имеетсн 
тип длл расчета некоторои страховои суммвг. Ему может потребоватБСи доступ 
к актуарнБш таблицам. Вместо встраиванин актуарнвгх таблиц в исходнбш код 
можно вклгочитб соответствугогции фаил с даннвши в состав сборки (например, 
с помогцбго компоновгцика сборок AL.exe, которвш рассмотрен далее). В сборки 
можно вклгочатБ даннБге в лгобом формате: в текстовом, в виде таблиц Microsoft 
Excel или Microsoft Word, а также в лгобом другом при условгш, что приложение 
способно разобратв даннБге в зтом формате. 

□ Сборки могут состоитб из типов, написаннБгх на разннгх нзБгках программиро- 
вангш. Одна частв типов может 6бгтб написана на С#, другал — на Visual Basic, 
осталБНБге — на других изнгках программировангш. При компилиции исходного 
текста на нзвгке C# компилитор создает один модулн, а при компилицгш ис- 
ходного текста на Visual Basic — другои. Затем при помогци соответствугогцего 
инструмента все зти модули обБединнготсн в одну сборку. ИсполБзугогцие такуго 
сборку разработчики увидлт в неи лишб набор типов. Разработчики даже не за- 
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метит, что применнлисћ разнме измки программированин. Кстати, при желании 
с помогцбк) ILDasm.exe можно получитћ фаилм с исходнмм текстом всех моду- 
леи на нзмке IL. После зтого можно запуститБ утилиту ILAsm.exe и передатБ еи 
полученнме фаилм, и утилита вмдаст фаил, содержагции все типм. Дли зтого 
компилнтор исходного текста должен генерироватБ то./њко IL -код. 


ВНИМАНИЕ 

Подводл итог, можно сказати, что сборка — зто единица многократного исполвзо- 
ванил, управленил версилми и безопасности типов. Она позволлет распределлтв 
типм и ресурсм по отделинмм фаилам, чтобм ее полвзователи могли решити, какие 
фаилм упаковиватв и pa3BepTbieaTb вместе. Загрузив фаил с манифестом, среда 
CLR может определити, какие фаилм сборки содержат типм и pecypcbi, на которме 
ссмлаетси приложение. Лкзбому потребителкз сборки достаточно знати лиши имл 
фаила, содержаидего манифест, после чего он сможет, не нарушач работм прило- 
женил, абстрагироватисп от особенностеи распределенич содержимого сборки по 
фаилам, которое со временем может менлтвсл. 

При работе со многими типами, совместно исполизукицими одну версино и набор 
параметров безопасности, по соображеничм производителиности рекомендуетсл 
размеш,ати все типи! в одном фаиле, не распределчп их по несколиким фаилам, не 
говорп уже о pa3Hbix сборках. На загрузку каждого фаила или сборки CLR и Windows 
тратчт значителБное времи: на поиск сборки, ее загрузку и инициализацик). Чем 
MeHbLue фаилов и сборок, тем бмстрее загрузка, потому уменвшение числа сборок 
способствует сокраиденик) рабочего пространства и степени фрагментации адрес- 
ного пространства процесса. Ну, и наконец, nGen.exe лучше оптимизируеткод, если 
обрабатмваемме фаилм болвше по размеру. 


Чтобм скомпоноватБ сборку, нужно вмбратБ один из РЕ-фаилов, которми ста- 
нет хранителем манифеста. Можно также создатБ отделБншд РЕ-фаил, в котором 
не будет ничего, кроме манифеста. В табл. 2.3 перечисленБг таблицБг метаданнБгх 
манифеста, наличие котормх преврагцает управлнемћги модулБ в сборку. 


Таблица 2.3. Таблица метаданнц|х манифеста 


Имлтаблицм 

метаданнмх 

манифеста 

Описание 

AssemblyDef 

Состоит из единственнои записи, если модулБ идентифицирует 
сборку. Записв вклгочает имл сборки (без расширенил и пути), 
сведешш о версии (старшии и младшии номера версии, номер 
компоновки и редакции), регионалвнБге стандартБ1, флаги, 
алгоритм хешированил и открБ1твш клгоч издателл (зто поле 
может 6б1тб пустБгм — null) 


продолжение & 
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Таблица 2.3 (продолжение) 


Имк ТаблИЦБ! 

метаданнБ1х 

манифеста 

Описание 

FileDef 

Содержит по однои записи длн каждого РЕ-фаила и фаила ре- 
сурсов, входдших в состав сборки (кроме фаила, содержагцего 
манифест). В каждои записи содержитсл имл и расширение 
фаила (без указании пути), хеш-код и флаги. Если сборка со- 
стоит из одного фаила, таблица FileDef пуста 

ManifestResourceDef 

Содержит по однои записи длл каждого ресурса, вклгоченного 
в сборку. Каждал записв вклгочает имл ресурса, флаги (public 
или private), а также индекс длн таблицм FileDef, указвгваго- 
гции фаил или поток с ресурсом. Если ресурс не лвллетсл от- 
делвннм фаилом (например, JPEG- или GIF -фаилом), он хра- 
нитсл в виде потока в составе РЕ-фаила. В случае встроенного 
ресурса записг. также содержит смшцение, указг. 1 вакмцее начало 
потока ресурса в РЕ-фаиле 

ExportedTypesDef 

Содержит записи длл всех открштшх типов, зкспортируемвк 
всеми РЕ-модуллми сборки. В каждои записи указано имл 
типа, индекс длл таблицш FileDef (указвгвакиции фаил сборки, 
в котором реализован зтот тип), а также индекс длн таблицн 
TypeDef. Примечание: длл зкономии фаилового пространства 
типвг, зкспортируемвхе из фаила, содержашего манифест, не 
повториготсн в зтои таблице, потому что информацил типов до- 
ступна через таблицвг TypeDef метаданнБгх 


Манифест позволиет потребителим сборки абстрагироватБСи от особенностеи 
распределенгш ее содержимого и делает сборку самоописћшаемои. Обратите вни- 
мание, что в фаиле, которми содержит манифест, находитси также информации 
о том, какие фашш составлнгот сборку, но отделБНБге фаилБ1 «не знагот», что они 
вклгоченБг в сборку. 

ПРИМЕЧАНИЕ 

Фаил сборки, содержаидии манифест, содержиттакже таблицу AssemblyRef. В неи 
храннтсл записи с описанием всех сборок, на которме ссмлакггса фаилм даннои 
сборки. Зто позволлет инструментам, открив манифест сборки, сразу увидетБ 
весБ набор сборок, на которме ccbmaeTca зта сборка, не открмваа другие фаилм 
сборки. И в зтом случае даннме AssemblyRef призванм сделати сборку самоопи- 
смваемои. 


Компилитор C# создает сборку, если указан лгобои из параметров команд- 
нои строки — /t[arget] :ехе, /t[arget]:winexe, /t[arget] : appcontainerexe, 
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/t[arget] :library или /t[arget] :winmdobj‘. Каждми из зтих параметров за- 
ставлнет компилитор генерироватв единми РЕ-фаил с таблицами метаданнмх 
манифеста. В итоге генерируетсл соответственно консолБное приложение, прило- 
жение с графическим интерфеисом, исполннемми фаил Windows Store, библиотека 
классов или библиотека WINMD. 

Кроме зтих параметров компилнтор C# поддерживает параметр /t [ а rget ]: module, 
KOTopbiii заставлнет компиллтор создатБ РЕ-фаил без таблиц метаданнмх манифеста. 
При исполћзовании зтого параметра всегда получаетсл DLL -фаил в формате РЕ. 
Длл того чтобм получитБ доступ к типам такого фаила, его необходимо поместитБ 
в сборку. При указании параметра /t : module компилитор C# по умолчаншо при- 
сваивает вмходному фаилу расширение .netmodule. 

ВНИМАНИЕ 

Ксожаленикз, в интегрированнои среде разработки (Integrated Development Environment, 
IDE) Microsoft Visual Studio нет встроеннои поддержки созданич многофаиловнх сбо- 
рок — длч зтого приходитсч исполвзоватв инструментв! команднои строки. 


Сугцествует несколБКО способов добавленип модули в сборку. Если РЕ-фаил 
с манифестом строитсн при помогци компилнтора С#, можно применитБ параметр 
/addmodule. Длл того 4To6bi noHHTb, как создагот многофаиловме сборки, рассмотрим 
пример. Допустим, ecTb два фаила с исходнмм текстом: 

□ фаил RUT.cs содержит редко исполвзуемме типм; 

□ фаил FUT.cs содержит часто исполвзуемме типм. 

Скомпилируем редко исполвзуемме типм в отделвнми модулв, чтобм полвзова- 
тели сборки могли отказатвсн от развертмванин зтого модули, если содержагциеси 
в нем типм им не нужнм: 

csc /t:module RUT.cs 

Команда заставлнет компилнтор C# создатв фаил RUT.netmodule, которми пред- 
ставлнет собои стандартнуго РЕ-библиотеку DLL, но среда CLR не сможет просто 
загрузитп ее. 

Tenepb скомпилируем в отделвном модуле часто исполвзуемме типм и сделаем 
его хранителем манифеста сборки, так как к расположеннмм в нем типам обрагца- 
готси доволвно часто. Фактически Tenepb зтот модул i> представлиет собои целуго 
сборку, позтому н изменил имн вмходного фаила с FUT.dll на MultiFileLibrary.dll: 

csc /out:MultiFileLibrary . dll /t:library /addmodule:RUT.netmodule FUT.cs 


1 При исполБЗОвании параметра /t[arget]:winmdobj полученнни фаил ,winmdobj должен 
6biTb передан программе WinMDExp.exe, которши немного обрабатнвает метаданнше 
длн представленил открнтнх типов CLR сборки как типов Windows Runtime. Программа 
WinMDExp.exe никак не затрагивает код IL. 
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Зта команда приказмвает компилнтору C# при компшшции фаила FUT.cs создатБ 
фаил MultiFileLibrary.dll. Посколћку указан параметр /t:library, резулБтирукзгции 
РЕ-фаил DLL с таблицами метаданнмх манифеста назмваетсн MultiFileLibrary.dll. 
Параметр /addmodule : RUT.netmodule указмваеткомпилнтору,чтофаил RUT.net- 
module должен 6мтб частБК) сборки. В частности, параметр /addmodule заставлиет 
компилитор добавитБ к таблице FileDef в метаданнмх манифеста сведении об 
зтом фаиле, а также занести в таблицу ExportedTypesDef сведешш об открмтмх 
зкспортируеммх типах зтого фаила. 

Завершив работу, компилнтор создаст несколБКО фаилов (рис. 2.1). МодулБ 
справа содержит манифест. 

Фаил RUT.netmodule содержит IL -код, сгенерированнми при компилнции RUT.cs. 
Кроме того, зтот фаил содержит таблицм метаданнмх, описмвакзгцие типм, методм, 
поли, своиства, собмтгш и т. п., определеннме в RUT.cs, а также типм, методм и др., 
на которме ссмлаетсн RUT.cs. MultiFileLibrary.dll — зто отделБнми фаил. Подобно RUT. 
netmodule, он вклгочает IL -код, сгенерированнБпг при компилнции FUT.cs, а также 
аналогичнБге метаданнћге в виде таблиц определении и ссбшок. Однако MultiFileLi- 
brary.dll также содержит дополнителБНБге таблицБг метаданнБгх, которБге и делагот 
его сборкои. Зти дополнителБНБге таблицБг описБгвагот все фаилвг, составлигогцие 
сборку (сам фаил MultiFileLibrary.dll и RUT.netmodule). Таблицвг метаданнБгх мани- 
феста также вклгочагот описание всех открвгтвгх типов, зкспортируемвгх фаилами 
MultiFileLibrary.dll и RUT.netmodule. 

ПРИМЕЧАНИЕ 

На самом деле в таблицах метаданнмх манифеста не описанм типб 1 , зкспортируемме 
РЕ-фаилом, в котором находитсл манифест. ЦелБ зтои оптимизации — уменБшитБ 
число баит, необходимое дпл храненил даннмх манифеста в РЕ-фаиле. Таким образом, 
утвержденил вроде «таблицБ 1 метаданнмх манифеста вклкзчакзт все открмтБ 1 е типм, 
зкспортируемме MultiFileLibrary.dll и RUT.netmodule«, вернБ! липљ отчасти. Однако 
зто утверждение вполне точно отражает логическии набор зкспортируемБ 1 х типов. 


Построив сборку MultiFileLibrary.dll, можно изучитв ее таблицБг метаданнБгх ма- 
нифестапри помогци ILDasm.exe, чтобнг убедитнсн, что фаил сборки деиствителБно 
содержит ссбглки на типбг из фаила RUT.netmodule. ТаблицБг метаданнБгх FileDef 
и ExportedTypesDef вбгглидит следугогцим образом: 

File #i (26000001) 

Token: 0x26000001 
Name : RUT.netmodule 

HashValue Blob : еб еб df 62 2c al 2c 59 97 65 0f 21 44 10 15 96 f2 7e db c2 

Flags : [ContainsMetaData] (00000000) 

ExportedType #1 (27000001) 


Token: 0x27000001 
Name: ARarelyUsedType 
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Implementation token: 0x26000001 

TypeDef token: 0x02000002 

Flags : [Public] [AutoLayout] [Class] [Sealed] [AnsiClass] 

[BeforeFieldlnit](00100101) 

Из зтих сведении видно, что RUT.netmodule — зто фаил, которми считаетси ча- 
стбк) сборки с маркером 0x26000001. Таблица ExportedType показмвает наличие 
открмтого зкспортируемого типа ARarelyUsedType. Зтот тип помечен маркером 
реализации (implementation token) 0x26000001, означаговдим, что IL -код зтого типа 
находитсл в фаиле RUT.netmodule. 

RUT.netmodule 


IL -код, сгенерированнми 
при компилнции RUT.cs 


МетаданнБ1е 

Типн, методБ! и другие суидности, 
onpefleneHHbie в RUT.cs 
Типн, MeTOflbi и другие суидности, 
на которне сснлаетсн RUT.cs 


Рис. 2.1. Многофаиловав сборка из двух управллеммх модулеи и манифеста 


MultiFileLibrary.dll 


IL -код, сгенерированнвш 
при компилвции FUT.cs 


МетаданнБ1е 

Типн, методн и т. д., 
определеннне в FUT.cs 
Типм, методн и т. д., 
на которме сснлаетсл FUT.cs 


Манифест 

Фаилс! сборки 

(MultiFileLibrary.dll и RUT.netmodule) 
OTKpbiTbie фаилм сборки 
(MultiFileLibrary.dll и RUT.netmodule) 


ПРИМЕЧАНИЕ 

Длв лкзбопмтнмх: размер маркеров метаданнмх — 4 баита. Старшии баит указмвает 
тип маркера (0x01=TypeRef, 0x02=TypeDef, 0x26=FileRef, 0x27=ExportedType). Пол- 
Hbin списоктипов маркеров см. в перечислимом типе СогТокепТуре в заголовочном 
фаиле CorHdr.h из .NET Framework SDK. Три младших баита маркера просто иден- 
тифицирунзт записћ в соответствунзвдеи таблице метаданнмх. Например, маркер 
реализации 0x26000001 ссмлаетсн на первунз строку таблицм FileRef (в болгзшинстве 
таблиц нумерацин строк начинаетсл с 1, а не с 0). Кстати, в TypeDef нумерацин строк 
начинаетсн с 2. 


Лгобои клиентскии код, исполћзуговдии типм сборки MultiFileLibrary.dll, должен ком- 
поноватћсн с указаниемпараметракомпилитора / г [eference] :MultlFileLibrary . 
dll, которми заставлнет компилнтор загрузитц сборку MultiFileLibrary.dll и все фаилм, 
перечисленнме в ее таблице FileDef . Компилнтору необходимо, чтобм все фаилм 
сборки бмли установленм и доступнм. Если удалитБ фаил RUT.netmodule, компи- 
лнтор C# вмдаст следуговдее сообвдение об ошибке: 
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fatal error CS0009: Metadata file 'C:\MultiFileLibrary.dll' could not be 
opened-'Error importing module 'rut.netmodule' of assembly 
'C:\MultiFileLibrary.dll'- The system cannot find the file specified 

Зто означает, что при построении новои сборки должни присутствоватБ все 
фаилБр на которБ1е она ссБшаетсч. 

Во времн исполненич клиентскии код вБ13Б1вает разнБге методБ 1 . При первом 
вБ130ве некоторого метода среда CLR определлет, на какие типб 1 он ссБшаетсл как 
на параметр, возврагцаемое значение или локалвнук) переменнукх Далее CLR пбн 
таетсл загрузитБ из сборки, на которуго сскшаетсл код, фаил с манифестом. Если 
зтот фаил описБшает типбц к которкш обрагцаетсл вБ13ваннБ1и метод, срабатБшагот 
внутренние механизмБ 1 CLR, и нужнБ 1 е типб 1 становитсн доступнвши. Если в ма- 
нифесте указано, что нужнвш тип находитсл в другом фаиле, CLR загружает зтот 
фаил, и внутренние механизмБ 1 CLR обеспечивагот доступ к данному типу. CLR 
загружает фаил сборки толбко при вкгоове метода, ссБшагогцегоси на расположен- 
нбш в зтом фаиле тип. Зто значит, что наличие всех фаилов сборки, на которуго 
ссвшаетси приложение, длн его работБ! не облзателто. 


Добавление сборок в проект в среде Visual Studio 

Если проект создаетсн в среде Visual Studio, необходимо добавитв в проект все 
сборки, на которвге он ссвшаетсл. Длл зтого откроите окно Solution Explorer, гцелкните 
правои кнопкои мбшш на проекте, на которкги нужно добавитк ссбшку, и вкгберите 
команду Add Reference. Откроетсл диалоговое окно Reference Manager (рис, 2.2). 
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Рис. 2.2. Диалоговое окно Reference Manager в Visual Studio 
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Дли того чтобм добавитд в проект ссмлку на сборку, вмберите ее в списке. Если 
в списке нет нужнои сборки, то длл того чтобм ее наити (фаил с манифестом), 
гцелкните на кнопке Browse. Вкладка Solution служит длн добавленгш в текугции 
проект ссмлки на сборкн, созданнме в другом проекте зтого же решенин. Раздел СОМ 
в диалоговом окне Reference Manager позволнет получитБ доступ к неуправлнемому 
СОМ-серверу из управлиемого кода через класс-представителБ, автоматически 
генерируемми Visual Studio. Вкладка Browse позволиет вмбратБ сборку, недавно 
добавленнуго в другои проект. 

Чтобм сборки отображалисБ в списке на вкладке .NET, вмполните инструкции 
по адресу: 

http://msdn.micnosoft . com/en-us/library/wkze6zky(v=vs.110).aspx 


ИсполБЗОвание утилитм Assembly Linker 

Вместо компилитора C# длл созданин сборки можно задеиствоватБ компоновгцик 
сборок (assembly linker) AL.exe. Зта утилита оказмваетсн кстати, если нужно созда- 
ватг> сборки из модулеи, скомпонованнБгх разнБши компилнторами (если компи- 
лнтор нзБгка не поддерживает параметр, зквивалентнБш параметру /addmodule из 
С#), а также в случае, когда требовангш к упаковке сборки на момент компоновки 
просто не известнБг. Утилита AL.exe пригодна и длн компоновки сборок, состонгцих 
исклгочителБно из ресурсов (или сопутствугогцих сборок — к ним мб1 егце вернемсн), 
которвге о6бгчно исполБзуготсл длл локализации ПО. 

Утилита AL.exe может генерироватБ фаилБГ формата ЕХЕ или DLL РЕ, которнге не 
содержат ничего, кроме манифеста, описБшагогцего типбг из других модулеи. Что6бг 
поннтб, как работает AL.exe, скомпонуем сборку MultiFileLibrary.dll по-другому: 

csc /t:module RUT.cs 
csc /t:module FUT.cs 

al /out: MultiFileLibnany.dll /t:librany FUT.netmodule RUT.netmodule 

ФаилБг, генерируемБге в резулвтате исполненгш зтих команд, показанБг на рис. 2.3. 
В зтом примере создаготсн два отделвнБгх модулн, RUT.netmodule и FUT.netmodule. 
Оба модулн не лвлнготсн сборками, так как не содержат таблиц метаданнвгх манифе- 
ста. Третии же — MultiFileLibrary.dll — зто неболБшан библиотека РЕ DLL (посколБку 
она скомпонована с параметром /t [ arget ]: library), в которои нет IL -кода, а толбко 
таблицБг метаданнБгх манифеста, указБшагогцие, что фаилБг RUT.netmodule и FUT. 
netmodule входлт в состав сборки. РезулБтиругогцач сборка состоит из трех фаилов: 
MultiFileLibrary.dll, RUT.netmodule и FUT.netmodule, так как компоновгцик сборок не 
«умеет» обБединнтБ несколБКО фаилов в один. 

Утилита AL.exe может генерироватв РЕ-фаилБ1 с консолбнбш и графическим 
интерфеисом, а также фаилБг приложении Windows Store с помогцбго параметров 
/t[arget] :ехе, /t[arget]:winexe или /t[arget]:appcontainerexe). Однако зто 
доволбно необБгчно, посколБку означает, что будет сгенерирован исполниемБпТ 
РЕ-фаил, содержагции не болнше IL -кода, чем нужно дли вкгзова метода из другого 
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модулн. Чтобм указатБ, какои метод должен исполБЗОватћсн в качестве входнои 
точки, задаите при ввкзове компоновшика сборок параметр команднои строки 
/main. Приведем пример ввшова AL.exe с зтим параметром: 

csc /trmodule /r:MultiFileLibrary . d 11 Program.es 
al /out:Program.exe /t:exe /main:Program.Main Program.netmodule 


RUT.netmodule RUT.netmodule 




IL -код, сгенерированнвт 
при компилации RUT.cs 




MeTaflaHHbie 

Tnnbi, MeTOflbi и другие сутности, 
определеннме в RUT.cs 

Ти п bi , Meroflbi и другие сушности, 
на KOTopbie ccbmaeTce RUT.cs 





IL -код, сгенерированнБТ 
при компиллции FUT.cs 




Метаданнме 

Типу, методи и т.д., 
onpefleneHHbie в FUT.cs 

Типм, методм и т.д., 
на которме ссмлаетсе FUT.cs 



MultiFileLibrary.dll 


(IL -код отсутствует) 

МетаданнБ1е 

Таблицн сснлок 
и определении отсутствук)т 


Манифест 

Фаилн сборки (MultiFileUbrary.dll, 
RUT.netmodule и FUT.netmodule) 
Открнтне фаилн сборки 
(RUT.netmodule и FUT.netmodule) 


Рис. 2.3. Многофаиловаи сборка из трех управллеммх модулеи и манифеста 

Перваи строка компонует Program.es в модулв, а вторан генерирует неболвшои 
РЕ-фаил Program.exe с таблицами метаданнБгх манифеста. В нем также находитси 
неболБшан глобалБнан функцил, сгенерированнан AL.exe благодарн параметру 
/main: Program.Main. Зтафункцгш,_ EntryPoint, содержит следуклции IL -код: 

.method privatescope static void _EntryPoint$PST06000001() cil managed 

{ 

.entrypoint 

// Code size 8 (0x8) 

.maxstack 8 
IL_0000: tail. 

IL_00@2: call void [.module 'Program.netmodule'JProgram::Main() 

IL_0007: ret 

} // end of method 'Global Functions'::_EntryPoint 
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Как видите, зтот код просто вмзмвает метод Main, содержатциисн в типе Program, 
которми определен в фаиле Program.netmodule. Параметр /main, указаннми при 
вмзове AL.exe, здсс r, не слишком полезен, так как врид ли вм когда-либо будете 
создаватБ приложение, у которого точка входа расположена не в РЕ-фаиле с табли- 
цами метаданнмх манифеста. Здесћ зтот параметр упоминут липп. дли того, чтобм 
вм знали о его сугцествовании. 

В программном коде длн даннои книги имеетсн фаил Ch02-3-BuildMultiFileLibrary. 
bat, в котором инкапсулированм последователмго все шагн построенин многофаило- 
Boii сборки. Проект Ch02-4-AppUsingMultiFileLibrary в Visual Studio ввшолннет даннми 
фаил на зтапе предварителБного построенин. Изучение зтого примера поможет вам 
понитб, как интегрироватБ многофаиловуго сборку из Visual Studio. 


Вклк)чение в сборку фаилов ресурсов 

Если сборка создаетсл с AL.exe, параметр /embed[resource] позволиет добавитБ 
в сборку фаилм ресурсов (фаилм в формате, отличном от РЕ). Параметр принима- 
ет лгобои фаил и вклгочает его содержимое в резулкгиругогции РЕ-фаил. Таблица 
ManifestResourceDef в манифесте обновлиетси, отражаи наличие нового ресурса. 

Утилита AL.exe поддерживает также параметр /link [ resource ], которми при- 
нимает фаил с ресурсами. Однако параметр то.п.ко обновлнет таблицм манифеста 
ManifestResourceDef и FileDef сведенгшми о ресурсе и о том, в каком фаиле 
сборки он находитсн. Сам фаил с ресурсами не внедриетсн в РЕ-фаил сборки, 
а хранитси отдс.п.по и подлежит упаковке и развертмваниго вместе с осталБнмми 
фаилами сборки. 

ПРИМЕЧАНИЕ 

Вфаилахуправллемои сборки содержитсл также фаил манифеста\Мп32. Поумолчаник) 
компиллтор C# автоматически создает фаил манифеста, однако ему можно запретиљ 
зто делатв при помоиди параметра /nowin32manifest. Программнми код манифеста, 
генерируемого компиллтором C# по умолчанику вмгллдит следукшдим образом: 

<?xml version="1.0" encoding="UTF8" standalone="yes" ?> 

<assembly xmlns="urn:schemasmicrosoftcom:asm.vl" manifestVersion="l.0"> 
<assemblyldentity version="l.0.0.0" name="MyApplication.app" /> 

<trustInfo xmlns="urn:schemasmicrosoftcom:asm.v2"> 

<security> 

<requestedPrivileges xmlns="urn:schemasmicrosoftcom:asm.v3"> 
<requestedExecutionLevel level="asInvoker" uiAccess="false"/> 
</requestedPrivileges> 

</security> 

</trustInfo> 

</assembly> 


Подобно AL.exe, CSC.exe позволиет обп.еди1тт, ресурсм со сборкои, генериру- 
емои компиллтором С#. Параметр /resource компилитора C# вклгочает указан- 
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Hbiii фаил с ресурсами в резулБтирунмции РЕ-фаил сборки и обновлиет таблицу 
ManifestResourceDef . Параметр компилнтора /linkresource добавлнет в таблицм 
Manif est ResourceDef и F ileDef записи co ссмлкои на отделБнми фаил с ресурсами. 

И последнее: в сборку можно вклјочитб стандартнме ресурсм Win32. Зто лег- 
ко сделатћ, указав при вмзове AL.exe или CSC.exe путћ к RES -фаилу и параметр 
/win32res. Кроме того, можно легко вклкзчитб стандартнБш ресурс значка Win32 
в фаил сборки, указав при вБ 130 ве AL.exe или CSC.exe путБ к ICO -фаилу и пара- 
метр /win32icon. В Visual Studio фаил ресурсов добавлнгот в сборку на вкладке 
Application в диалоговом окне своиств проекта. 06бшно значки вклгочагот, что 6 б 1 
Проводник Windows (Windows Explorer) мог отображатБ значок длн управлнемого 
исполннемого фаила. 


Ресурсн со сведенилми о версии сборки 

Когда утилита AL.exe или CSC.exe генерирует сборку в виде РЕ-фаила, она также 
вклгочает в зтот фаил стандартнБ1и ресурс версии Win32. ПолБЗОватели могут уви- 
детБ версиго, просматриваи своиства фаила. Длн получении зтои информации из 
программБ1 служит статическии метод GetVersionlnfo типа System. Diagnostics . 
FileVersionlnfo. На рис. 2.4 показана вкладка Details диалогового окна своиств 
фаила Ch02-3-MultiFileUbrary.dll. 


Ch02-3-MultiFiieLibrary.dll Properties х 


| General | SecufHy | Details | 


I Property 

Value 

г»__ 

UCSLIipLIUri 


File descriplion 

MultiFileLibrary.dll 

Туре 

Application extension 

File version 

1.0.G.G 

Product name 

Wintellect (R) MultiFileLibrary's Туре Lib... 

Product version 

2.0.0.0 

1 Copyright 

Copyright (c) Wintellect 2013 S 

Size 

5.00 KB 

Date modified 

6/18/2012 2:36 PM 

Language 

Language Neutral 

Legal trademarks 

MultiFileLibrary is a registered trademark... 

Original filename 

СИ02-3-М ultiFileLibrary. dll 

Remove ProDerties and Personal Information 


ОК | | Cancel | | Apply 


Рис. 2.4. Вкладка Details диалогового окна своиств фаила Ch02-3-MultiFileLibrary.dll 
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При построении сборки следует задаватБ значенин полеи версии в исходном 
тексте программБ1 с iiomoihiho специализированнБ1х атрибутов, применпемБ1х на 
уровне сборки. Вот как вбшллдит код, генерируклции информацшо о версии, по- 
казаннуго на рис. 2.4. 
using System.Reflection; 

// Информацип версии полн FileDescription : 

[assembly : AssemblyTitleCMultiFileLibrary.dll" ) ] 

// Информацин версии полн Comments: 

[assembly: AssemblyDescription("This assembly contains MultiFileLibrary's types")] 

// Информацив версии полн CompanyName: 

[assembly: AssemblyCompany("Wintellect")] 

// Информацин версии полн ProductName: 

[assembly: AssemblyProduct("Wintellect (R) MultiFileLibrary's Туре Library")] 

// Информацин версии полн LegalCopyright: 

[assembly: AssemblyCopyright("Copyright (c) Wintellect 2013")] 

// Информацин версии полн LegalTrademarks: 

[assembly:AssemblyTrademark("MultiFileLibrary is a registered trademark 

of Wintellect")] 

// Информацин версии полн AssemblyVersion: 

[assembly: AssemblyVersion("3.0.0.0")] 

// Информацин версии полв FILEVERSION/FileVersion: 

[assembly: AssemblyFileVersion("1.0.0.0")] 

// Информацин версии полн PRODUCTVERSION/ProductVersion: 

[assembly: AssemblyInformationalVersion("2.0.0.0")] 

// Задатц поле Language (см. далее раздел "Регионалцнне стандартн") 

[assembly : AssemblyCulture( "")] 


ВНИМАНИЕ 

Ксожаленшо, в диалоговом окне своиств npoBOflHHKaWindows отсутствукзт полл длл 
некоторихатрибутов. В частности, 6bmo 6w оченБудобно, если 6bi в нем отображалсл 
атрибут AssemblyVersion, потому что среда CLR исполизуетзначение зтого атрибута 
при загрузке сборки (об зтом рассказано в главе 3). 


В табл. 2.4 перечисленБг поли ресурса со сведенинми о версии и соответствукзгцие 
им атрибутћц определиемБге полБЗОвателем. Если сборка компонуетси утилитои 
AL.exe, сведенгш о версии можно задатв параметрами команднои строки вместо 
атрибутов. Во втором столбце табл. 2.4 показанвг параметрБг команднои строки длн 
каждого полн ресурса со сведенинми о версии. Обратите внимание на отсутствие 
аналогичнБгх параметров у компиллтора С#; позтому сведенгш о версии обвгчно 
задагот, применпи специализированнБге атрибутБг. 
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Таблица 2.4. Полн ресурса со сведенинми о версии и соответствукхцие 
им параметрн AL.exe и полвзователвские атрибутв! 


Поле ресурса 
со сведенилми 

о версии 

Параметр AL.exe 

Атрибут/комментарии 

FILEVERSION 

/fileversion 

System. Reflection. 
AssemblyFileVersionAttribute 

PRODU CTVERSION 

/productversion 

System.Reflection.AssemblyInformational- 

VersionAttribute 

FILEFLAGSMASK 

Нет 

Всегда задаетсл равнБМ VS FFI 
FILEFLAGSMASK (определлетсл 
в WinVer.h как 0x0000003F) 

FILEFLAGS 

Нет 

Всегда равен 0 

FILEOS 

Нет 

B настолгцее времл всегда равен VOS 
WINDOWS32 

FILETYPE 

/target 

Задаетсл равнвгм VFT_APP, если задан 
параметр /target:exe или /target:winexe. 

При наличии параметра /target:library 
приравниваетсл VFT_DLL 

FILESUBTYPE 

Нет 

Всегда задаетсл равнБш VFT2 

UNKNOWN (зто поле не имеет значенил 
длл VFT APP и VFT DLL) 

AssemblyVersion 

/version 

System. Reflection. 

AssemblyVersionAttribute 

Comments 

/description 

System. Reflection. 
AssemblyDescriptionAttribute 

CompanyName 

/сотрапу 

System. Reflection. 
AssemblyCompanyAttribute 

FileDescription 

/title 

System.Reflection.AssemblyTitleAttribute 

FileVersion 

/version 

System. Reflection. 

AssemblyVersionAttribute 

InternalName 

/out 

Задаетсл равнвгм заданному имени ввгход- 
ного фаила (без расширенин) 

LegalCopyright 

/ copyright 

System. Reflection. 
AssemblyCopyrightAttribute 

LegalTrademarks 

/trademark 

System. Reflection. 
AssemblyTrademarkAttribute 
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Поле ресурса 
со сведенилми 

о версии 

Параметр AL.exe 

Атрибут/комментарии 

OriginalFilename 

/out 

Задаетсл равнћгм заданному имени ввгход- 
ного фаила (без пути) 

PrivateBuild 

Р1ет 

Всегда остаетсл пуствгм 

ProductName 

/product 

System. Reflection. 

AssemblyProductAttribute 

ProductVersion 

/productversion 

System.Reflection.AssemblyInformational- 

VersionAttribute 

SpecialBuild 

Р1ет 

Всегда остаетсл пустћш 


ВНИМАНИЕ 

При создании нового проекта C# в Visual Studio фаил Assemblylnfo.cs генерируетсл 
автоматически. Он содержит всеатрибути сборки, описаннме взтом разделе, атакже 
несколвко дополнителвнмх — о них penb идет в главе 3. Можно просто открмти фаил 
Assemblylnfo.cs и изменити относлидиесл кконкретнои сборкесведенил. Visual Studio 
также предоставллет диалоговое окно длл редактированил информации о версии 
сборки, которое изображено на рис. 2.5. 



Рис. 2.5. Диалоговое окно с информациеи о сборке в Visual Studio 
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Номера версии 

Ранее бмло показано, что сборка может идентифицироватБСн по номеру версии. 
У частеи зтого номера одинаковћш формат: каждал состоит из 4 частеи, разделен- 
нб 1 х точками (табл. 2.5). 


Таблица 2.5. Формат номеров версии 



Старшии 

номер 

Младшии 

номер 

Номер 

компоновки 

Номер 

редакции 

Пример 

2 

5 

719 

2 


В табл. 2.5 показан пример номера версии 2.5.719.2. I lepisbie две цифрБ 1 состав- 
лшот то, что обвгано понимагот под номером версии: полвзователи будут считатв 
номером версии 2.5. Третве число, 719, указвшает номер построенгш. Если в вашеи 
компании сборка строитси каждвш денБ, увеличиватБ зтот номер надо ежедневно. 
Последнее число 2 — номер редакции сборки. Если в компании сборка строитсл 
дваждБ1 в денБ (скажем, после исправленин критическои и облзателвнои к не- 
медленному исправлениго ошибки, тормозившеи всго работу над проектом), надо 
увеличиватв номер редакции. Такаи схема нумерации версии принита в компании 
Microsoft, и 'А настоителБно рекомендуго eii следоватБ. 

Обратите внимание: со сборкои свлзанБ 1 три номера версии. Зто оченв неудачное 
решение стало источником серкезнои путаницБ 1 . Попробуго о6бнсиитб, длл чего 
нужен каждБш из зтих номеров и как его правилвно исполБЗОватБ. 

□ AssemblyFileVersion — зтот номер версии хранитсл в ресурсе версии Win32 
и предназначен лишб длн информации, CLR его полностбго игнорирует. 06бшно 
устанавливагот старшии и младшии номера версии, определнгогцие отображаемвпт 
номер версии. Далее при каждои компоновке увеличивагот номер компоновки и 
редакции. Теоретически инструмент от компании Microsoft (например, CSC.exe 
или AL.exe) должен автоматически обновлитв номера компоновки и редакции 
(в зависимости от датБ 1 и времени на момент компоновки), но зтого не проис- 
ходит. Зтот номер версии отображаетси Проводником Windows и служит длн 
определентш точного времени компоновки сборки. 

□ AssemblyInformationalVersion — зтот номер версии также хранитси в ресурсе 
версии Win32 и, как и предБвдугции, предназначен лншб длл информации; CLR 
его игнорирует. Зтот номер служит длн указантш версии продукта, в которвпт 
входит сборка. Например, продукт верстти 2.0 может состоитб из несколБКих 
сборок. Одна из них может отмечатнси как верстш 1.0, если зто нован сборка, не 
входившаи в комплект поставки продукта версии 1.0. Обвшно отображаемвш 
номер версии формируетсл из старшего и младшего номеров версии. Затем 
номера компоновки и редакции увеличивагот при каждои упаковке всех сборок 
готового продукта. 




РегионалБнне стандар™ 
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□ AssemblyVersion — зтот номер версии хранитсн в манифесте, в таблице мета- 
даннмх AssemblyDef . CLR исполБзует зтот номер версии длл привнзки к сбор- 
кам, имеклцим строгие имена (о них рассказано в главе 3). Зтот номер версии 
чрезвБгчаино важен, так как он однозначно идентифицирует сборку. Начинаи 
разработку сборки, следует задатБ старшии и младшии номера версии, а также 
номера компоновки и редакции; не менните их, пока не будете готовбг начатБ 
работу над следуготеи версиеи сборки, пригоднои длл развертБ 1 ванил. При 
создании сборки, ссвшагогцеисн на другуго, зтот номер версии вклгочаетсл в нее 
в виде записи таблицБг As semblyRef . Зто значит, что сборка знает, с какои верси- 
еи она бвша построена и протестирована. CLR может загрузитв другуго версиго, 
исполвзул механизм перенаправленгш привнзки, описаннвш в главе 3. 


РегионалБнне стандартн 

Помимо номера версии, сборки идентифициругот регионалкними стандартами 
(culture). Например, одна сборка может 6бгтб исклгочителБно на немецком нзкгке, 
другаи — на швеицарском варианте немецкого, третви — на американском англии- 
ском и т. д. РегионалБНБге стандартБг идентифицируготсл строкои, содержагцеи 
основнои и вспомогателБНБш теги (как описано в RFC1766). Несколвко примеров 
приведено в табл. 2.6. 


Таблица 2.6. Примерн тегов, определчгоидих регионалБНБ1е стандартБ! сборки 


Основноитег 

ВспомогателБНБ1и тег 

РегионалБнме стандартм 

De 

Нет 

Немецкии 

De 

AT 

Австриискии немецкии 

De 

сн 

Швеицарскии немецкии 

En 

Нет 

Англиискии 

En 

GB 

Англиискии 

En 

us 

Англиискии 


В обгцем случае сборкам с кодом не назначагот регионалБНБге стандартБг, так как 
код обкгчно не содержит завислгцих от них встроеннвгх параметров. Сборку, длл 
которои не определен регионалвнБш стандарт, назБгвагот сборкои с нептралтими 
регионалтими стандартами (culture neutral). 

При создании приложенгш, ресурсБг которого привнзанБг к регионалБНБш стан- 
дартам, компангш Microsoft настолтелБно рекомендует обБединнтБ программнБпг 
ресурс и ресурсБг приложенгш по умолчаниго в однои сборке и не назначатв еи 
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регионалћнмх стандартов при построении. Другие сборки будут ссмлатБСн на нее 
при создании и работе с типами, которме она предоставлнет длл обгцего доступа. 

После отого можно создатБ одну или несколнко отделБнкгх сборок, содержагцих 
толбко ресурс bi , зависшцие от регионалвнБгх стандартов, и никакого программ- 
ного кода. Сборки, помеченнвге дли примененгш в определеннвгх регионалБНБгх 
стандартах, назншагот сопутствутцими (satellite assemblies). РегионалБНБге стан- 
дартБг, назначеннБге такои сборке, в точностгг отражагот регионалвнБге стандартБг 
размегценного в неи ресурса. Рекомендуетси создаватв отделвнуго сопутствугогцуго 
сборку дли каждого регионалвного стандарта, которнги вбг намеренБг поддержггватБ. 

06бгчно сопутствугогцгге сборкгг строитсн пргг помогци утилитвг AL.exe. Не стоггт 
ггсполБЗОватБ дли зтого компгглнтор — ведБ в сопутствугогцеи сборке не должно 6 бгтб 
программного кода. Прггменнн утгглггту AL.exe, можно задатн желаемБге регионалБ- 
нБге стандартБг параметром / с [ ulture] : text, где text — зто строка (например, en-US, 
представлигогцаи американскгги вариант англггиского нзвгка). Пргг развертБгвании 
сопутствугогцие сборкгг следует помегцатв в подкаталог, ими которого совпадает 
с текстовои строкои, идентифициругогцеи регионалБнвге стандартБг. Например, еслгг 
базовБгм каталогом приложенгш нвлнетси C:\MyApp, сопутствугогцан сборка длн аме- 
риканского варианта англггиского нзвгка должна 6 бгтб в каталоге C:\MyApp\en-US. Во 
времн вБгполнешш доступ к ресурсам сопутствугогцеи сборкгг осугцествлнгот через 
класс System . Resources . ResourceManager. 

ПРИМЕЧАНИЕ 

Хота зто и не рекомендуетсч, можно создаватБ сопутствукдцие сборки с программ- 
HbiM кодом. При желании вместо параметра /culture утилитм AL.exe регионалБнми 
стандарт можноуказаљ в атрибуте System.Reflection.AssemblyCulture, определлемом 
полБЗОвателем, например, следукнцим образом: 

// НазначитБ длн сборки регионалвнни стандарт Swiss German 
[assembly : AssemblyCulture("de-CH")] 

B обгцем случае не стоит создаватв сборки, ссБглагогциеси на сопутствугогцие 
сборки. Другими словами, все записи таблицвг AssemblyRef должнбг ссбглдтбсн на 
сборки с неитралБНБгми регионалБНБгми стандартами. Если необходимо получитБ 
доступ к типам или членам, расположеннБгм в сопутствугогцеи сборке, следует вос- 
полвзоватБСи механизмом отражепии (см. главу 23). 


Развертмвание простнх приложении 
(закрмтое развертнвание сборок) 


Ранее в зтои главе бвгло показано, как строитв модули и обБединнтБ их в сборки. 
Пора занитБСи упаковкои и развертвгванием сборок, чтобвг полвзователв мог ра- 
ботатБ с приложением. 
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Дли приложении Windows Store устанавливаготси исклгочителБно жесткие 
правила упаковки сборок. Visual Studio упаковмвает все сборки, необходимме 
приложениго, в один фаил .аррх, которми либо отправллетсл в Windows Store, 
либо загружаетсл на машину. Когда полБЗОвателБ устанавливает фаил .аррх, все 
содержагциеси в нем сборки помегцаготсл в каталог, из которого CLR загружает 
их, а Windows добавлнет плитку приложенгш на началг>нми зкран полБЗОвателн. 
Если другие полБЗОватели установнт тот же фаил .аррх, будут исполБЗОванм ранее 
установленнме сборки, а у нового полБЗОвателн на пача.њпо.м зкране просто до- 
бавитсн плитка. Когда полБЗОвателБ удалнет приложение Windows Store, система 
удалиет плитку с началБного зкрана полБЗОвателн. Если приложение не установлено 
у других полвзователеи, Windows уничтожает каталог вместе со всеми сборками. 
Eie забвшаите, что разнвге полБЗОватели могут устанавливатв разнБге версии одного 
приложешш Windows Store. Учитвшаи такуго возможностб, Windows устанавлива- 
ет сборки в разнБге каталоги, что6б1 несколБКО версии одного приложенин могли 
одновременно сугцествоватв на однои машине. 

Длн настолБНБгх приложении (не относигцихсн к Windows Store) особкгх средств 
дли упаковки сборки не требуетсн. Легче всего упаковатв набор сборок, просто ско- 
пировав все их фаилвг. Е1апример, можно поместитБ все фаилвг сборки на компакт- 
диск и передатБ их полБЗОвателго вместе с программои установки, написаннои 
в виде пакетного фаила. Такан программа просто копирует фаилвг с компакт-диска 
в каталог на жестком диске полвзователи. Посколвку сборка вклгочает все ссбглки 
и ТИПБ 1 , определнгогцие ее работу, ему достаточно запуститн приложение, а CLR 
наидет в каталоге приложенгш все сборки, на которвге ссвшаетсн даннан сборка. Так 
что дли запуска приложенгш не нужно модифицироватБ реестр, а что6бг удалитБ 
приложение, достаточно просто удалитБ его фаилБг — и все! 

Конечно, можно применнтБ дли упаковки и установки сборок другие механиз- 
мб 1 , например САВ-фаилБ 1 (они обншно исполБзуготси в сценаринх с загрузкои из 
Интернета дли сжатин фаилов и сокрагценин времени загрузки). Можно также 
упаковатв фаилБг сборки в MSI -фаил, предназначеннвш длл службБг установгци- 
ка Windows (Windows Installer), MSIExec.exe. MSI позволиет установитв сборку 
по требованиго при первои попвгтке CLR ее загрузитк. Зта функцгш не нова дли 
службвг MSI, она также поддерживает аналогичнуго функциго длл неуправлиемБгх 
ЕХЕ- и DLL -фаилов. 

ПРИМЕЧАНИЕ 

ПакетнБ 1 и фаил или подобнал простал «установочнал программа» скопирует при- 
ложение на машину полБЗОвателл, однако длл созданил лрлБ1ков на рабочем столе, 
в менк) Пуск (Start) и на панели бмстрого запуска понадобитсп программа посложнее. 
Кроме того, скопироватБ, восстановиљ или переместиљ приложение с однои машинм 
на другукз легко, но ссмлки и прлмки потребукзт специалБного обраиденил. 


Естественно, в Visual Studio еств встроеннБге механизмБг, которБге можно задеи- 
ствоватБ длн публикации приложении, — зто делаетсн на вкладке Publish страницвг 
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своиств проекта. Можно исполБЗОватБ ее, чтобм заставитБ Visual Studio создатБ 
MSI -фаил и скопироватБ его на веб-саит, FTP -саит или в заданнуго папку на диске. 
MSI -фаил также может установитв все необходимБ 1 е компонентБ 1 , такие как .NET 
Framework или Microsoft SQL Server Express Edition. Наконец, приложение может 
автоматически провернтв наличие обновлении и устанавливатв их на полБЗОвателБ- 
скои машине посредством технологии ClickOnce. 

Сборки, развертБ 1 ваемБ 1 е в том же каталоге, что и приложение, назвшагот сбор- 
ками с закритиш развертиванием (privately deployed assemblies), так как фашш 
сборки не исполБзуготсн совместно другими приложенинми (если толбко другие 
приложенин не развертБ 1 вагот в том же каталоге). Сборки с закрвмБш развертБ 1 - 
ванием — сервезное преимугцество длл разработчиков, конечнБ1х полБЗОвателеи 
и администраторов, посколвку достаточно скопироватБ такие сборки в базоввш 
каталог приложенин, и CLR сможет загрузитк и исполнитб содержагциисл в них 
код. Приложение легко удаллетсл; длл зтого достаточно удалитв сборки из его ка- 
талога. Также упрогцаготсл процедурБ 1 резервного копировангш и восстановленгш 
подобнвгх сборок. 

НесложнБш сценарии установки/перемегценил/удаленин приложенгш стал воз- 
можнбгм благодарн наличиго в каждои сборке метаданнвгх. МетаданнБге указБгвагот, 
какуго сборку, на которуго они ссвглаготси, нужно загрузитБ — длл зтого не нужннг 
параметрБг реестра. Кроме того, областБ видимости сборки охватвгвает все типбг. 
Зто значит, что приложение всегда привнзБгваетсл именно к тому типу, с которвгм 
оно бвгло скомпоновано и протестировано. CLR не станет загружатв другуго сборку 
просто потому, что она предоставлиет тип с тем же именем. Зтим CLR отличаетсн 
от СОМ, где типбг регистрируготси в системном реестре, что делает их доступнвгми 
лгобому приложениго, работагогцему на машине. 

В главе 3 рассказано о развертБгвании совместно исполвзуемБгх сборок, доступ- 
нбгх несколБКим приложенгшм. 


Простое средство администрированил 
(конфигурационнми фаил) 

ПолБЗОватели и администраторвг лучше всех могут определлтв разнБге аспектБг 
работБг приложенгш. Например, администратор может решитн переместитБ фагглБг 
сборкгг на жесткии диск полБЗОвателн гглгг заменитв даннБге в манггфесте сборкгг. 
Естб и другие сценарии управленгш версинми и удаленного админггстрировангш, 
о некоторвгх из нггх рассказано в главе 3. 

Длл того чтобвг предоставггтв адмггнггстратору контролБ над прггложением, можно 
разместитБ в каталоге приложенгш конфигурационнвги фаил. Его может создатБ 
и упаковатБ издателБ прггложенггн, после чего программа установкгг запишет кон- 
фгггурационнБги фаил в базоввги каталог приложенггн. Кроме того, админггстратор 
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или конечнми полћзователћ машинм может сам создатБ или модифицироватБ зтот 
фаил. CLR интерпретирует его содержимое длн измененин политики поиска и за- 
грузки фаилов сборки. 

КонфигурационнБШ фаилБ 1 содержат XML-Tern и могут ассоциироватБСл 
с приложением или с компБнзтером. ИсполБЗОвание отделвного фаила (вместо 
параметров, хранимвш в реестре) позволнет легко создатв резервнуго копиго фаила, 
а администратору — без труда копироватв фаилБ1 с машинБ1 на машину: достаточно 
скопироватБ нужшле фашш — в резулвтате будет также скопирована администра- 
тивнан политика. 

В главе 3 такои конфигурационнБ 1 и фаил рассматриваетсл подробно, а пока 
вкратце обсудим его. Допустим, издателв хочет развернутБ приложение вместе 
с фаилами сборки MultiFileLibrary, но в отделвном каталоге. Желаеман структура 
каталогов с фаилами вбшллдит следугогцим образом: 

Каталог AppDir (содержит фаилн сборки приложенил) 

Program.exe 

Program.exe. config (обсуждаетсл ниже) 

Подкаталог AuxFiles (содержит фаилн сборки MultiFileLibrary) 

MultiFileLibrary.dll 
FUT.netmodule 
RUT.netmodule 

ПосколБку фаилБ 1 сборки MultiFileLibrary более не находлтси в базовом ката- 
логе приложенгш, CLR не сможет наити и загрузитв их, и при запуске приложенгш 
будет сгенерировано исклгочение System . 10. FileNotFoundException. 4to6bi избе- 
жатБ зтого, издателБ создает конфигурационнБш фаил в формате XML и размегцает 
его в базовом каталоге приложенгш. Имн зтого фаила должно совпадатв с именем 
главного фаила сборки и иметв расширение config, в данном случае — Program.exe. 
config. Содержимое зтого конфигурационного фаила должно ввшлидетБ примерно 
следуклцим образом: 

<configuration> 

<runtime> 

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.vl"> 

<probing privatePath="AuxFiles" /> 

</assemblyBinding> 

</runtime> 

</configuration> 

11 1 >п ажт> наити фаил сборки, CLR всегда сначала игцет в каталоге приложенгш, 
и если поиск заканчиваетсн неудачеи, продолжает искатв в подкаталоге AuxFiles. 
В атрибуте privatePath злемента, направлнгогцего поиск, можно указатв несколБКО 
путеи, разделеннБ 1 Х точкои с запнтои. Считаетсн, что все пути заданБ 1 относителБно 
базового каталога приложенгш. Идел заклгочаетси в том, что приложение может 
управлитБ своим каталогом и его подкаталогами, но не может управлитв другими 
каталогами. 
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Алгоритм поиска фаилов сборки 

В поиске сборки среда CLR просматривает несколБКО подкаталогов. Порндок при 
поиске сборки с неитралБнмми регионалБНБши стандартами таков (при условии, 
что параметрБ1 f irstPrivatePath и secondPrivatePath определенБ1 в атрибуте 
privatePath конфигурационного фаила): 

AppDir\AsmName.dll 
AppDir\AsmName\AsmName.dll 
AppDir\firstPrivatePath\AsmName.dll 
AppDir\firstPrivatePath\AsmName\AsmName.dll 
AppDir\secondPrivatePath\AsmName.dll 
AppDir\secondPrivatePath\AsmName\AsmName . dll 


B зтом примере конфигурационнБпг фаил не понадобитсн, если фаилБ1 сборки 
MultiFileLibrary развернутБ1 в подкаталоге MultiFileLibrary, так как CLR автома- 
тически проверлет подкаталог, имн которого совпадает с именем искомои сборки. 

Если ни в одном из упомлнутБгх каталогов сборка не наидена, CLR начинает поиск 
заново, но теперв игцет фаил с расширением ЕХЕ вместо DLL. Если и на зтот раз поиск 
оканчиваетсл неудачеи, генерируетсл исклгочение FileNotFoundException. 

В отношении сопутствугогцих сборок деиствугот те же правила поиска за одним 
исклгочением: ожидаетсл, что сборка находитсл в подкаталоге базового каталога 
приложенгш, имн которого совпадает с названием регионалвного стандарта. На- 
пример, если длл фаила AsmName.dll назначен регионалБНБги стандарт «en-US», 
порндок просмотра каталогов таков: 

С: \AppDir\enUS\AsmName.dll 

С: \AppDir\enUS\AsmName\AsmName.dll 

С: \AppDir\firstPrivatePath\enUS\AsmName.dll 

С: \AppDir\firstPrivatePath\enUS\AsmName\AsmName.dll 

С: \AppDir\secondPrivatePath\enUS\AsmName.dll 

С: \AppDir\secondPrivatePath\enUS\AsmName\AsmName.dll 

С: \AppDir\enUS\AsmName .ехе 

С: \AppDir\enUS\AsmName\AsmName .ехе 

С: \AppDir\firstPrivatePath\enUS\AsmName.exe 

С: \AppDir\firstPrivatePath\enUS\AsmName\AsmName.exe 

С: \AppDir\secondPrivatePath\enUS\AsmName.exe 

С: \AppDir\secondPrivatePath\enUS\AsmName\AsmName.exe 

С: \AppDir\en\AsmName.dll 

С: \AppDir\en\AsmName\AsmName . dll 

С: \AppDir\firstPrivatePath\en\AsmName.dll 

С: \AppDir\firstPrivatePath\en\AsmName\AsmName.dll 

С: \AppDir\secondPrivatePath\en\AsmName.dll 

С: \AppDir\secondPrivatePath\en\AsmName\AsmName.dll 

С: \AppDir\en\AsmName .ехе 
С: \AppDir\en\AsmName\AsmName .ехе 
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С: \AppDir\f irstPrivatePath\en\AsmName .ехе 
С: \AppDir\firstPrivatePath\en\AsmName\AsmName.exe 
С: \AppDir\secondPrivatePath\en\AsmName.exe 
С: \AppDir\secondPrivatePath\en\AsmName\AsmName .ехе 

Как видите, CLR шцет фаилм с расширением ЕХЕ или DLL. ПосколБку поиск 
может заниматБ значителБное времн (особенно когда CLR пБ 1 таетсл наити фаилБ 1 
в сети), в конфигурационном ХМП-фаиле можно указатв один или несколБКО зле- 
ментов региоиалБНБ1х стандартов culture, hto6bi ограничитБ круг провериемБ1Х 
каталогов при поиске сопутствугогцих сборок. Microsoft предоставлнет программу 
FusLogVw.exe, при помогци которои можно увидетв, как CLR осугцествлнет привпзку 
сборок во времл вБшолненгш. ДополнителБнап информацгш доступна по адресу 
http://msdn.microsoft.com/en-us/library/e74a1 8c4(v=vs.1 10). aspx. 

Ими и расположение конфигурационного XМ L -фаила может различатБСи в за- 
висимости от типа приложенгш. 

□ Длн исполннемБгх приложении (ЕХЕ) конфигурационнБш фаил должен рас- 
полагатБСн в базовом каталоге приложенгш. У него должно 6бгтб то же имн, что 
и у ЕХЕ-фаила, но с расширением config. 

□ Длн приложении Microsoft ASRNET Web Form конфигурационнБШ фаил всегда 
должен находитБСл в виртуалвном корневом каталоге веб-приложенгш и на- 
ЗБшатвсл VVeb.config. Кроме того, в каждом вложенном каталоге может 6бггб 
собственнБш фаил VVeb.config с унаследованнБгми параметрами конфигурацгш. 
Например, веб-приложение, расположенное по адресу http://www.Wintellect.com/ 
Training, будет исполвзоватБ параметрБг из фаилов Web.config, расположеннвгх 
в виртуалБном корневом каталоге и в подкаталоге Training. 

Как уже 6бшо сказано, параметрБг конфигурацгш применнготсц к конкретному 
приложениго и конкретному компБготеру. При установке платформа ,NET Framework 
создает фаил Machine.config. Сугцествует по одному фаилу Machine.config на каж- 
дуго версиго средвг CLR, установленнуго на даннои машине. Фаил Machine.config 
расположен в следугогцем каталоге: 

%SystemRoot%\Microsoft . NET\Framework\6epcufl\C0NFIG 

Естественно, %SystemRoot% — зто каталог, в котором установлена система 
Windows (обвгчно C:\Windows), а версил — номер версии, идентифициругогции 
определеннуго версиго платформвг .NET Framework (например, v4.0. #####). 

Параметрнг фаила Machine.config заменнгот параметрБг конфигурационного 
фаила конкретного приложенгш. Администраторам и полБЗОвателлм следует 
избегатв модификацгш фаила Machine.config, посколБку в нем хранитсл многие 
параметрвг, свнзаннБге с самБгми разнБши аспектами работнг системБг, что серБезно 
затрудннет ориентациго в его содержимом. Кроме того, конфигурационнБге фаилБц 
специфичнБге длл приложенгш, упрогцагот организациго резервного копировангш 
и восстановленгш конфигурацгш приложенгш. 



Глава 3 . Совместно исполвзуемне 
сборки и сборки со строгим 
именем 


В главе 2 говорилосћ о построении, упаковке и развертмвании сборок. При зтом 
основное внимание уделилосБ закритому развертиваншо (private deployment), 
при котором сборки, предназначеннме исклгочителг>но длл одного приложенгш, 
помегцагот в базовми каталог приложенгш или в его подкаталог. Закрмтое раз- 
вертмвание сборок позволиет в значителћнои мере управлнтБ именами, версиими 
и поведением сборок. 

В зтои главе мм заимемси созданием сборок, которме могут совместно испо./њ- 
зоватБСи несколБКими приложенгшми. ЗамечателБнми пример глобалћно развер- 
тмваеммх сборок — зто сборки, поставлнемме вместе с Microsoft .NET Framework, 
посколБку почти все управлнемме приложенин исполћзугот типм, определеннме 
Microsoft в библиотеке классов .NET Framework Class Library (FCL). 

Как уже бмло отмечено в главе 2, операционнап система Windows полЈшила репу- 
тациго нестабилБнои главнмм образом из-за того, что длн созданин и тестировангш 
приложении приходитси исполБЗОватБ чужои код. В конце концов, лгобое прило- 
жение дли Windows, которое вм пишете, вмзмвает код, созданнми разработчиками 
Microsoft. Более того, самме разнме компании производлт злементм управленгш, 
которме разработчики затем встраивагот в свои приложешш. Фактически такои 
подход стимулирует сама платформа .NET Framework, а со временем, вероитно, 
число производителеи злементов управленгш возрастет. 

Времи не стоит на месте, как и разработчики из Microsoft, как и сторонние про- 
изводители злементов управлешш: они устранигот ошибки, добавлнгот в свои код 
новме возможности и т. п. В конечном счете, на жесткии диск полг>зователг>ского 
компБготера попадает новми код. В резулшате в давно установленном и прекрасно 
работавшем полг>зователг>ском приложении начинает исполБЗОватБСн уже не тот 
код, с которкгм оно создавалосБ и тестировалосБ. Поведение такого приложенгш 
становитси непредсказуемБгм, что, в свого очередв, негативно влгшет на стабилв- 
ностб Windows. 

РешитБ проблему управленгш версгшми фаилов чрезвБгчаино трудно. На самом 
деле, н готов споритв, что если взнтб лгобои фаил и изменитБ в нем значение одного- 
единственного бита с 0 на 1 или наоборот, то никто не сможет гарантироватв, что 
программБг, исполБЗОвавшие исходнуго версиго зтого фаила, будут работатв с новои 
версиеи фаила, как ни в чем не бБгвало. Зто утверждение верно хоти 6бг потому, что 
многие программБг случаино или преднамеренно зксплуатиругот ошибки других 
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программ. Если в более позднеи версии кода какан-либо ошибка будет исправлена, 
то исполћзуклцее его приложение начинает работатв непредсказуемо. 

Итак, вопрос в следугогцем: как, устрании ошибки и добавлнн к программам 
новме функции, гарантироватБ, что зти измененин не нарушат работу других при- 
ложении? Л долго думал над зтим и пришел к вмводу — зто просто невозможно. 
Но, очевидно, такои ответ не устроит никого, посколћку в поставлнеммх фаилах 
всегда будут ошибки, а разработчики всегда будут одержимм желанием добавлитБ 
HOBbie функции. Должен все же 6мтб способ распространенин новмх фаилов, по- 
зволнгогции надентБСн, что лгобое приложение после обновленин продолжит заме- 
чателБно работатБ, а если нет, то легко вернутБ приложение в последнее состонние, 
в котором оно прекрасно работало. 

В зтои главе описана инфраструктура .NET Framework, призваннан решитБ про- 
блемБ1 управленгш версгшми. ПозволБте сразу предупредитБ: речБ идет о сложнбгх 
матергшх. Нам придетсн рассмотретБ массу алгоритмов, правил и политик, встроен- 
Hbix в обгцеизБ 1 Ковуго исполннгогцуго среду (CLR). Помимо зтого, упомннутБ 1 многие 
инструментБ1 и утилитБ1, которБши приходитсн полБЗОватБСн разработчику. Все зто 
достаточно сложно, посколБку, как н уже сказал, проблема управленгш версгшми 
непроста сама по себе и то же можно сказатБ о подходах к ее решениго. 


Два вида сборок — два вида развертнванил 

Среда CLR поддерживает два вида сборок: с нестрогими именами (weakly named 
assemblies) и со строгими именами (strongly named assemblies). 

ВНИМАНИЕ 

Bbi никогда не встретите термин «сборка с нестрогим именем» в документации по 
.NET Framework. Почему? А потому, что ч сам его придумал. В деиствителБности 
в документации неттермина длл обозначенил сборки, у которои отсутствуетстрогое 
имл. 9 решил обозначитБтакие сборки специалБнмм термином, чтобм потексту 6bmo 
однозначно понлтно, о каких сборках идет речш 


Сборки со строгими и нестрогими именами имегот идентичнуго структуру, то естБ 
в них исполБзуетсн фаиловБш формат РЕ (portable executable), заголовок РЕ32(+), 
CLR -заголовок, метаданнБге, таблицБ 1 манифеста, а также IL -код, рассмотреннБпг 
в главах 1 и 2. Оба типа сборок компонуготсн при помогци одних и тех же инстру- 
ментов, например компшштора C# или AL.exe. В деиствителБности сборки со стро- 
гими и нестрогими именами отличаготсл тем, что первше подписанБ 1 при помогци 
napbi клгочеи, уникалБно идентифициругогцеи издатели сборки. Зта пара клгочеи 
позволнет уникалБно идентифицироватБ сборку, обеспечиватБ ее безопасностБ, 
управлнтБ ее версгшми, а также развертБшатБ в лгобом месте полБЗОвателБСКого 
жесткого диска или даже в Интернете. Возможностб уннкалБнои идентификацгш 
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сборки позволнет CLR при попмтке привжзки приложенин к сборке со строгим 
именем применитБ определеннме политики, которме гарантиругот безопасностБ. 
Зта глава посвнгцена разЂиснениго сугцности сборок со строгим именем и политик, 
применнемБгх к ним со CTopoin.i CLR. 

РазвертБшание сборки может 6бгтб закрБгтБш или глобалБНБш. Сборки первого 
типа развертБшаготсн в базовом каталоге приложентш или в одном из его подката- 
логов. Длн сборки с нестрогим именем возможно лишб закрБгтое развертБшание. 
О сборках с закрБгтБш развертБшанием речБ шла в главе 2. Сборку с глобалвнБш 
развертБшанием устанавливагот в каком-либо обгцеизвестном каталоге, которвш 
CLR провернет при поиске сборок. Такие сборки можно развертвшатБ как закркгто, 
так и глобалБно. В зтои главе обЂнснено, как создагот и разверткшагот сборки со 
строгим именем. Сведенин о типах сборок и способах их развертвшашш представ- 
ленБ! в табл. 3.1. 


Таблица 3.1. ВозможнБ 1 е способн развертБ 1 ванип сборок 
со строгими и нестрогими именами 


Тип сборки 

Закрмтое 

развертмвание 

ГлобалБное 

развертшвание 

Сборка с нестрогим именем 

Да 

Нет 

Сборка со строгим именем 

Да 

Да 


Назначение сборке строгого имени 

Если сборка должна исполБЗОватБСн несколБКими приложенинми, ее следует по- 
меститБ в обгцеизвестнБш каталог, которкш среда CLR должна автоматически про- 
веритв, обнаружив ссвшку на сборку. Однако при зтом возникает проблема — две 
(или болвше) компании могут вБшуститБ сборки с одинаковБши именами. Тогда, 
если обе зт и сборки будут скопированБ1 в один обгцеизвестнвги каталог, <<победит» 
последннн из них, а работа приложенгш, исполБЗОвавших первуго, нарушитсн — ведв 
перван при копировании заменнетсл второи (зто и нвлиетсл причинои <<кошмара 
DLL» в современнвгх системах Windows — все библиотеки DLL копируготсн в папку 
System32). 

Очевидно, одного имени фаила мало, чтобвг различатв две сборки. Среда CLR 
должна поддерживатБ некгш механизм, позволнгогцгш уникалвно идентифицироватБ 
сборку. Именно длл зтого и служат строгие имена. У сборки со строгим именем 
четБгре атрибута, уникалБно ее идентифициругогцих: ими фаила (без расширенгш), 
номер версгш, идентификатор регионалвного стандарта и открБгтБш клгоч. Посколб- 
ку открБгтБге клгочи представлигот собои оченв болБшие числа, вместо последнего 
атрибута исполвзуетси неболБшои хеш-код откркгтого клгоча, которкш назБшагот 






Назначение сборке строгого имени 


97 


маркером откритого клтча (public key token). Следукпцие четБфе строки, которћге 
иногда назБшагот отображаемБш именем сборки (assembly display name), иденти- 
фициругот совершенно разнше фаилБ! сборки: 


"MyTypes, 

"MyTypes, 

"MyTypes, 

"MyTypes, 


Version=l.0.8123.0, 
Version=l.0.8123.0, 
Version=2.0.1234.0, 
Version=l.0.8123.0, 


Culture=neutral, 

Culture="en-US", 

Culture=neutral, 

Culture=neutral, 


PublicKeyToken=b77a5c561934e089" 

PublicKeyToken=b77a5c561934e089" 

PublicKeyToken=b77a5c561934e089" 

PublicKeyToken=b03f5f7flld50a3a" 


Перваи строка идентифицирует фаил сборки MyTypes.exe или MyTypes.dll (на 
самом деле, по строке идентификации пе.њ.зз узнатв расширение фаила сборки). 
Компанин-производителБ назначила сборке номер версии 1.0.8123.0, в неи нет 
компонентов, зависимвгх от регионалБНБгх стандартов, так как атрибут Culture 
определен как neutral. Но сделатв сборку MyTypes.dll (или MyTypes.exe) с номе- 
ром версии 1.0.8123.0 и неитралвнБши регионалБНБши стандартами может лгобаи 
компании. 

Должен 6 б 1 тб способ отличитб сборку созданнуго зтои компаниеи, от сборок 
других компании, которнш случаино 6 бши назначенБ 1 те же атрибутБг В силу рида 
причин компанин Microsoft предпочла другим способам идентификации (при по- 
могци GUID, URL и URN) стандартнБге криптографические технологии, основан- 
HBie на паре из закрвгтого и открглтого клгочеи. В частности, криптографические 
технологии позволнгот проверцтв целостностБ даннБ1х сборки при установке ее на 
жесткии диск, а также назначатв разрешении доступа к сборке в зависимости от 
ее издателл. Все зти механизмБ 1 обсуждаготси далее в зтои главе. Итак, компании, 
желагогцаи снабдитв свои сборки уникалвнои меткои, должна получитн пару клго- 
чеи — открБПБш и закрБ1ТБш, после чего открБ1ТБш клгоч можно будет свизатн со 
сборкои. У всех компании будут разнвге napni клгочеи, позтому они смогут созда- 
ватв сборки с одинаковБши именами, версиими и регионалвнБши стандартами, не 
опасалсБ возникновенич конфликтов. 


ПРИМЕЧАНИЕ 

ВспомогателБНБш класс System.Reflection.AssemblyName позволлет легко генери- 
роватБ имл дли сборки, атакже получатБ отделБНБ 1 е части имени сборки. Он поддер- 
живает рлд OTKpbiTbix зкземпллрнБ 1 х своиств: Culturelnfo, FullName, KeyPair, Name и 
Version — и предоставллет OTKpbiTbie методн зкземпллров, такие как GetPublicKey, 
GetPublicKeyToken, SetPublicKey и SetPublicKeyToken. 


В главе 2 н показал, как назначитв имн фаилу сборки, как задатк номера версии 
и идентификатор регионалвного стандарта. У сборки с нестрогим именем атрибутБ 1 
номераверсии и регионалвнБгх стандартов могут 6бгтб iik. iiohciii.i в метаданнвге ма- 
нифеста. Однако в зтом случае CLR всегда игнорирует номер версии, а при поиске 
сопутствугогцих сборок исполвзует лишб идентификатор регионалБНБгх стандар- 
тов. Посколвку сборки с нестрогими именами всегда развертвшаготсл в закЈЛ.пом 
режиме, длл поиска фаила сборки в базовом каталоге приложенич или в одном из 
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его подкаталогов, указанном атрибутом pnivatePath конфигурационного XML- 
фаила, CLR просто берет имн сборки (добавлнн к нему расширение DLL или ЕХЕ). 

Кроме имени фаила, у сборки со строгим именем естг> номер версии и идентифи- 
катор регионалћнмх стандартов. Кроме того, она подписана при помогци закрнтого 
клгоча издатели. 

Первми зтап созданин такои сборки — получение клгоча при помогци утилитм 
Strong Name (SN.exe), поставлиемои в составе .NET Framework SDK и Microsoft 
Visual Studio. Зта утилита поддерживает множество функции, котормми полг>зу- 
кјтсз, задаван в команднои строке соответствугогцие параметрБг ЗаметБте: все пара- 
метрвг команднои строки SN.exe чувствителБНБг к регистру. Что6бг сгенерироватБ 
пару клгочеи, вБшолните следугогцуго команду: 

SN -k МуСотрапу. snk 

Зта команда заставит SN .ехе создатв фаил MyCompany.snk, содержагции открбгтбш 
и закрБгтБги клгочи в двоичном формате. 

Числа, образугогцие открвгтБги клгоч, оченк велики. При необходимости после 
создании зтого фаила можно исполвзоватБ SN.exe, что6бг увидетБ открбгтбш клгоч. 
Длн зтого нужно вбшолнитб SN.exe дваждБК сначала с параметром -р, что6бг создатБ 
фаил, содержагции толбко открбгтбш клгоч (МуСотрапу. РибИсКеу) 1 : 

SN -р МуСотрапу. keys МуСотрапу. PublicKey 

Затем SN.exe вБшолннетсл с параметром -tp с указанием фаила, содержагцего 
ОТКрБГТБШ клгоч: 

SN -tp MyCompany.PublicKey 

На своем компвготере л получил следугогции резулБтат: 

Microsoft (R) . NET Framework Strong Name Utility Version 4.0.30319.17929 
Copyright (c) Microsoft Corporation. All rights reserved. 

Public key (hash algorithm: sha256): 

00240000048000009400000006020000002400005253413100040000010001003f9d62lb702111 
850be453b92bd6a58c020eb7b804f75d67ab302047fc786ffa3797b669215afb4d814a6f294010 
b233bac0b8c8098ba809855da256d964c0d07fl6463d918d651a4846a62317328cac893626a550 
69f21al25bc03193261176dd629eace6c90d36858de3fcb781bfc8b817936a567cad608ae672b6 
Ifb80eb0 

Public key token is 3db32f38c8b42c9a 

При зтом невозможно заставитв SN.exe аналогичнБш образом отобразитБ за- 

КрБГТБШ КЛГОЧ. 


1 В зтом примере исполБзуетсн механизм Enhanced Strong Naming, понвившиисл в .NET 
Framework 4.5. Чтобм создатв сборку, совместимуго с предБ1душ,ими версинми .NET Framework, 
вам также придетсл создатв подписб другои сторонБГ (counter-signature) с исполБзованием 
атрибута AssemblySignatureKey. За подробностнми обрагцаитесБ по адресу http://msdn. 
microsoft.com/en-us/library/hh4 1 5055(v=vs. 11 0).aspx. 
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Болбшои размер открмтнх к. почси затрудннет работу с ними. Чтобм облегчитБ 
жизнб разработчику (и конечному полБЗОвателго), бмли созданм маркери от- 
критого клтча. Маркер открмтого клгоча — зто 64-разриднми хеш-код открмтого 
клгоча. Если вмзватБ утилиту SN.exe с параметром -tp, то после значенин клгоча 
она вбшодит соответствугогции маркер открвгтого клгоча. 

Теперв мб1 знаем, как создатк криптографическуго пару клгочеи, и получение 
сборки со строгим именем не должно вБгзкшатБ затруднении. При компилиции 
сборки необходимо задатк компилнтору параметр /keyf ile : имп_фапла\ 

csc /keyfile:MyCompany . snk Program.es 

Обнаружив в исходном тексте зтот параметр, компилнтор C# открвшает задан- 
нбш фаил (MyCompany.snk), подписБгвает сборку закрвгтБгм клгочом и встраивает 
открвгтБш клгоч в манифест сборки. Заметвте: подписБшаетсл лишб фаил сборки, 
содержагции манифест, другие фаилБг сборки нелкзи подписатБ нвно. 

В Visual Studio новаи пара клгочеи создаетсл в окне своиств проекта. Дли зтого 
переидите на вкладку Signing, установите флажок Sign the assembly, а затем в поле 
со списком Choose а strong name key file ввгберите вариант <New...>. 

Слова <<подписание фаила» означагот здесв следугогцее: при компоновке сборки 
со строгим именем в таблицу метаданнвгх манифеста FileDef заноситсн список всех 
фаилов, составлнгогцих зту сборку. Каждвш раз, когда к манифесту добавлнетсл имн 
фаила, рассчитБгваетсл хеш-код содержимого зтого фаила, и полученное значение 
сохраннетсл вместе с именем фаилав таблице FileDef . Можно заменитв алгоритм 
хешировангш, исполБзуемБпг по умолчаниго, вБгзвав AL.exe с параметром /algid 
или задав на уровне сборки следугогцгш атрибут, определлемБпг полБЗОвателем, — 
System . Reflection. AssemblyAlgorithmIdAttribute. По умолчаниго хеш-код вбг- 
числнетсн по алгоритму SHA-1. 

После компоновки РЕ-фаила с манифестом рассчитвшаетсл хеш-код всего со- 
держимого зтого фаила (за исклгочением подписи Authenticode Signature, строгого 
имени сборки и контролвнои суммБг заголовка РЕ), как показано на рис. 3.1. Д./ш 
зтои операции применнетсн алгоритм SHA-1, здесв его нелБЗи заменитБ никаким 
другим. Значение хеш-кода подписБшаетсл закрБгтБгм клгочом издателн, а по- 
лученнач в резулвтате цифровал подписб RSA заноситсл в зарезервированнвги 
раздел РЕ-фаила (при хешировании РЕ-фаила зтот раздел исклгочаетси), и в 
CLR -заголовок РЕ-фаила записБшаетси адрес, по которому встроеннаи цифрован 
подписб находитсл в фаиле. 

В зтот РЕ-фаил также встраиваетси открвгтвги клгоч издателл (он записБшаетсл 
в таблицу As semblyDef метаданнвгх манифеста). Комбинацгш имени фаила, версии 
сборки, регионалБНБгх стандартов и значенгш открвгтого клгоча составлнет строгое 
имн сборки, которое гарантированно нвлнетси уникалвнБш. Две разнвгх компании 
ни при каких обстонтелБСтвах не смогут создатв две одинаковБге сборки, скажем, 
с именем Calculus, с тои же napoii клгочеи (без нвнои передачи клгочеи). 

Теперв сборка и все ее фаилвг готовбг к упаковке и распространениго. 
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Calculus.dll 



Рис. 3.1. Подписание сборки 


Как отмечено в главе 2, при компилнции исходного текста компилитор обна- 
руживает все типм и членм, на которме ссмлаетсн исходнбш текст. Также ком- 
пиллтору необходимо указатБ все сборки, на которме ссмлаетси даннаи сборка. 
В случае компилитора C# дли зтого применнетсн параметр /neference. В задачу 
компилнтора входит внедрение таблицм метаданнмх AssemblyRef в резулети- 
ругогции управлиемми моду.т i>. Каждал записБ таблицм метаданнмх AssemblyRef 
описмвает фаил сборки, на которуго ссмлаетсн даннан сборка, и состоит из имени 
фаила сборки (без расширенгш), номера версии, регионалБного стандарта и значе- 
нгш открмтого клгоча. 

ВНИМАНИЕ 

Поскол^ку значение открнтого клк>ча велико, в том случае, когда сборка ссмлаетса на 
множество других сборок, значенил открмти 1 х кшочеи могут занлљ значителвнукз часљ 
резулвтирукшдего фаила. Длл зкономии места в компании М1сгозоПхеширук)тоткрм- 
тми клк)ч и берут последние 8 баит полученного хеш-кода. В таблице AssemblyRef на 
самом деле хранлтсл именно такие усеченнме значенил открмтого клк>ча — маркерм 
отрмтого клкзча. В обгцем случае разработчики и конечнме полизователи намного 
чаиде встречакзтси с маркерами, чем с полнмми значенилми клкзча. 

Вместе с тем нужно имети в виду, что среда CLR никогда не исполвзует маркерм от- 
крмтого клгача в процессе принлтич решении, касак> 1 цихсч безопасности или довериз, 
потому что одному маркеру может соответствоваљ несколико OTKpbiTbix клкзчеи. 


Далее приведенм метаданнме таблицм AssemblyRef (полученнме средствами 
ILDasm.exe) длл фаила MultiFileLibrary.dll, обсуждавшегоси в главе 2: 
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AssemblyRef #1 (23000001) 

Token: 0x23000001 

Public Кеу or Token: b7 7a 5c 56 19 34 e@ 89 

Name: mscorlib 

Version: 4.0.0.0 

Major Version: 0x00000004 

Minor Version: 0x00000000 

Build Number: 0x00000000 

Revision Number: 0x00000000 

Locale: <null> 

HashValue Blob: 

Flags: [none] (00000000) 

Из зтих сведении видно, что фаил MultiFileLibrary.dll ссмлаетсл на тип, располо- 
женнми в сборке со следукнцими атрибутами: 

"MSCorLib, Version=4. 0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" 

K сожаленшо, в утилите ILDasm.exe исполБзуетсл термин Locale, хоти насамом 
деле там должно 6мтб слово Culture. 

Взглннув на содержимое таблицм метаданнмх AssemblyDef фаила MultiFileLibrary. 
dll, мм увидим следукнцее: 

Assembly 

Token: 0x20000001 
Name : MultiFileLibrary 
Public Кеу : 

Hash Algorithm : 0x00008004 
Version: 3.0.0.0 
Major Version: 0x00000003 
Minor Version: 0x00000000 
Build Number: 0x00000000 
Revision Number: 0x00000000 
Locale: <null> 

Flags : [none] (00000000) 

Зто зквивалентно следукпцеи строке: 

"MultiFileLibrary, Version=3. 0.0.0, Culture=neutral, PublicKeyToken=null" 

Здесв открмтми клгоч не определен, посколмсу сборка MultiFileLibrary.dll, соз- 
даннаи в главе 2 , не бмла подписана открмтмм клгочом и, следователБно, нвлнетси 
сборкои с нестрогим именем. Если бм и создал фаил с клгочами при помогци ути- 
литм SN.exe, а затем скомпилировал сборку с параметром /keyf ile, то получиласБ 
бм подписаннаи сборка. Если просмотретБ метаданнБге полученнои таким образом 
сборки при помогци утилитБ1 ILDasm.exe, в соответствугогцеи записи таблицв1 
AssemblyDef обнаружитсл заполненное поле Public Кеу, говоригцее о том, что зто 
сборкасо строгим именем. Кстати, записБ таблицБ1 AssemblyDef всегдахранит пол- 
ное значение открБ1того клгоча, а не его маркер. Полнбш открБ1ТБШ клгоч гарантирует 




102 Глава 3. Совместно Mcnoab3yeMbie сборки и сборки со строгим именем 


целостностБ фаила. Позже н oiri.acmo принцип, лежашии в основе устоичивости 
к несанкционированнои модификации сборок со строгими именами. 


ГлобалБнњш кзш сборок 

ТеперБ Bbi знаете, как создаготсл сборки со строгим именем — пора научитБСл 
развертмватБ такие сборки и узнатБ, как CLR исполБзует метаданнБге длн поиска 
и загрузки сборки. 

Если сборка предназначена дли совместного исполБЗОвангш несколБКими при- 
ложенгшми, ее нужно поместитБ в обгцеизвестнБ1и каталог, которБ1и среда CLR 
должна автоматически проверлтБ при обнаружении ссбшки на сборку. Место, 
где располагаготсл совместно исполБзуемБге сборки, назБшагот глобалтим кзшем 
сборок (global assembly cache, GAC). Точное местонахождение GAC - подробностБ 
реализации, котораи может изменнтБСн в будугцих версгшх ,NET Framework. Тем 
не менее о6бгчно GAC находитсл в каталоге 

%SystemRoot%\Microsoft . NET\Assembly 

GAC имеет иерархическое строение и содержит множество вложеннБгх каталогов, 
имена которБгх генерируготси по определенному алгоритму. Ни в коем случае не 
следует копироватБ фаилБг сборок в GAC вручнуго — вместо зтого надо исполБЗОватБ 
инструментБг, созданнБге специалБно длн зтои цели. Зти инструментБг «знагот» вну- 
треннгого структуру GAC и умегот генерироватБ надлежагцие имена подкаталогов. 

В период разработки и тестировангш сборок со строгими именами длн установки 
их в каталог GAC чагце всего применнгот инструмент GACUtil.exe. ЗапугценнБш без 
параметров, он отобразит следугогцие сведенгш: 

Microsoft (R) . NET Global Assembly Cache Utility. Version 4.0.30319.17929 
Copyright (c) Microsoft Corporation. All rights reserved. 

Usage: Gacutil <command> [ <options> ] 

Commands: 

/i <assembly_path> [ /г <...> ] [ /f ] 

Installs an assembly to the global assembly cache. 

/il <assembly_path_list_file> [ /г <...> ] [ /f ] 

Installs one or more assemblies to the global assembly cache. 

/u <assembly_display_name> [ /г <...> ] 

Uninstalls an assembly from the global assembly cache. 

/ul <assembly_display_name_list_file> [ /г <...> ] 

Uninstalls one or more assemblies from the global assembly cache. 

/1 [ <assembly_name> ] 

List the global assembly cache filtered by <assembly_name> 
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/1г [ <assembly_name> ] 

List the global assembly cache with all traced references. 
/cdl 

Deletes the contents of the download cache 
/ldl 

Lists the contents of the download cache 


/? 

Displays a detailed help screen 
Options: 

/г <reference_scheme> <reference_id> <description> 

Specifies a traced reference to install (/i, /il) or uninstall (/u, /ul). 


/f 

Forces reinstall of an assembly. 

/nologo 

Suppresses display of the logo banner 
/silent 

Suppresses display of all output 

Ввмвав утилиту GACUtil.exe c параметром / i, можно установитБ сборку в ка- 
талог GAC, а с параметром /и сборка будет удалена из GAC. Обратите внимание, 
что сборку с нестрогим именем нелБЗи поместитБ в GAC. Если передатБ GACUtil. 
ехе фаил сборки с нестрогим именем, утилита вввдаст следукпцее сообгцение 
об ошибке (ошибка добавлешш сборки в кзш: nonbiTKa установитБ сборку без 
строгого имени): 

Failure adding assembly to the cache: Attempt to install an assembly 
without a strong name 


ПРИМЕЧАНИЕ 

По умолчаник) манипуллции с каталогом GAC могут осушествллтБ лишб членм группм 
Windows Administrators. GACUtil.exe не сможет установитБ или удалитБ сборку, если 
вмзвавшии утилиту полБЗОвателБ не входит в зту группу. 


Параметр /1 утилитБ 1 GACUtil.exe оченБ удобен длл разработчика во времи 
тестировангш. Однако при исполБЗОвании GACUtil.exe длл развертвшангш сборки 
в рабочеи среде рекомендуетсн применнтв параметр / r в дополнение к / i — при 
установке и / u — при удалении сборки. Параметр / r обеспечивает интеграцшо 
сборки с механизмом установки и удаленгш программ Windows. По сути вбгзов 
утилитБГ с зтим параметром сообгцает системе, дли какого приложенгш требуетсн 
зта сборка, и свнзБгвает их между собои. 
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ПРИМЕЧАНИЕ 

Если сборка со строгим именем упакована в САВ-фаил или сжата иннм способом, 
то, прежде чем устанавливати фаил сборки в каталог GAC при помош,и утилитм 
GACUtil.exe, следует распаковати его во временнми фаил, которми нужно удалити 
после установки сборки. 


Утилита GACUtil.exe не входит в состав свободно распространнемого пакета .NET 
Framework, предназначенного дли конечного полвзователл. Если в приложении 
естБ сборки, которше должнм развертмватБСн в каталоге GAC, исполБзуите про- 
грамму Windows Installer (MSI), так как зто единственнми инструмент, способнми 
установитћ сборки в GAC и гарантированно присутствугогции на машине конечного 
полћзователл. 

ВНИМАНИЕ 

Глобалвное развертивание сборки путем размеидениа ее в каталог GAC — зто один из 
видов регистрации сборки в системе, хотл зто никак незатрагивает peecTpWindows. 
Установка сборок в GAC делает невозможннми простне установку, копирование, 
восстановление, перенос и удаление приложенил. По зтои причине рекомендуетсч 
избегати глобалиного развертнванил и исполизоватв закри 1 тое развертнвание сборок 
вскјду, где зто толико возможно. 


Зачем «регистрироватБ» сборку в каталоге GAC? ПредставБте себе, что две ком- 
пании сделали каждан cboio сборку OurLibrary, состонгцуго из единственного фаила: 
OurLibrary.dll. Очевидно, зти фаилБг нелБЗи записБгватБ в один каталог, посколБку 
фаил, копируемБпг последним, перезапишет первБШ и тем самБгм нарушит работу 
какого-нибудБ приложенгш. Если длн установки в GAC исполБЗОватБ специалвнБШ 
инструмент, он создаст в каталоге %SystemRoot%\Microsoft.NET\Assembly отделБнвге 
папки длл каждои из зтих сборок и скопирует каждуго сборку в свого папку. 

06бгчно полБЗОватели не просматривагот структуру каталогов GAC, позтому 
дли вас она не имеет реалБного значенин. Доволбно того, что структура каталогов 
GAC известна CLR и инструментам, работагогцим с GAC. 


Построение сборки, ссБшак>1деисл 
на сборку со строгим именем 

Какуго 6bi сборку вбг ни строили, в резулБтате всегда получаетсн сборка, ссбг- 
лагогцаисн на другие сборки со строгими именами. Зто утверждение верно хотл 
6бг потому, что класс System.Object определен в MSCorLib.dll, сборке со строгим 
именем. Однако велика веронтностБ того, что сборка также будет ссБглатБСи на 
тгшБг из других сборок со строгими именами, изданнБгми Microsoft, сторонними 
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разработчиками либо созданнмми в вашеи организации. В главе 2 показано, как 
исполг>зоватБ компиллтор CSC.exe с параметром /reference длл определенил 
сборки, на которуго должна ссБшатћсн создаваемаи сборка. Если вместе с именем 
фаила задатв полнбш путБ к нему, CSC.exe загрузит указаннБпг фаил и исполБзует 
его метаданнБге длн построенгш сборки. Как отмечено в главе 2, если задано ими 
фаила без указангш пути, CSC.exe пБ 1 таетсл наити нужнуго сборку в следукзгцих 
каталогах (просматриван их в поридке перечисленгш). 

1 . Рабочии каталог. 

2. Каталог, где находитсл фаил CSC.exe. Зтот каталог также содержит DLL- 
библиотеки CLR. 

3 . Каталоги, заданнвге параметром / lib команднои строки компшштора. 

4 . Каталоги, указаннвге в переменнои окруженгш LIB. 

Таким образом, чтобвг скомпоноватв сборку, ссБглагогцугоси на фаил System. 
Drawing.dll разработки Microsoft, при вБгзове CSC.exe можно задатв параметр 
/reference : System . Drawing . d 11. Компиллтор проверит перечисленнБге ка- 
талоги и обнаружит фаил System.Drawing.dll в одном каталоге с фаилом CSC. 
ехе — том же, которвш содержит библиотеки DLL версии CLR, которуго сам 
исполвзует длл созданил сборки. Однако несмотри на то, что при компшшции 
сборка находитси в зтом каталоге, во времп вБгполненгш зта сборка загружаетсл 
из другого каталога. 

Дело в том, что во времи установки .NET Lramework все фаилвг сборок, создан- 
нБгх Microsoft, устанавливаготсн в двух зкземплнрах. Один набор фаилов заноситсн 
в один каталог с CLR, а другои — в каталог GAC. Фаилвг в каталоге CLR облегчагот 
построение полвзователБСКих сборок, а их копии в GAC предназначенвг длл загрузки 
во времн вБгполненгш. 

CSC.exe не игцет нужннге длл компоновки сборки в GAC, потому что длл зтого 
вам пришлосв 6бг задаватБ путБ к фаилу сборки, а структура GAC не документи- 
рована. Также можно бвшо бвг задаватв сборки при помогци не менее длиннои, но 
чутБ более изнгцнои строки вида: 

System.Drawing, Version=4. 0.0.0, Culture=neutral, PublicKeyToken= b03f5f7flld50a3a 

Оба способа бвгли настолвко неуклгожими, что 6бшо решено предпочестБ им 
установку на полвзователБСКии жесткии диск двух копии фаилов сборок. 

Кроме того, сборки в каталоге CLR не привнзанБг к машине. Иначе говори, зти 
сборки содержат толбко метаданнБге. Так как код IL не нужен на стадии построенгш, 
в зтом каталоге не нужно хранитв версии сборки длн х86, х64 и ARM. Сборки в GAC 
содержат метаданнвге и IL, потому что код нужен толбко во времл ввшолненгш. 
А посколБку код может оптимизироватБСн длн конкретнои архитектурБг процессора, 
в GAC могут хранитБСи несколБКО версии однои сборки; они находнтсл в разнвгх 
подкаталогах, соответствугогцих разнвш архитектурам процессоров. 
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Устоичивостб сборок со строгими именами 
к несанкционированнои модификации 

Подписание фаила закрмтмм клгочом и внедрение подписи и открмтого к. поча 
в сборку позволиет CLR убедитћсн в том, что сборка не бмла модифицирована или 
повреждена. При установке сборки в GAC система хеширует содержимое фаила 
с манифестом и сравнивает полученное значение с цифровои подписбго RSA, 
встроеннои в РЕ-фаил (после извлеченин подписи с iiomoihkio открмтого клгоча). 
ИдентичностБ значении означает, что содержимое фаила не бмло модифицировано. 
Кроме того, система хеширует содержимое других фаилов сборки и сравнивает по- 
лученнме значенин с таковмми из таблицм манифеста FileDef. Если хотк одно из 
значении не совпадает, значит хотн бм один из фаилов сборки бмл модифицирован 
и попмтка установки сборки в каталог GAC окончитсл неудачеи. 

Когда приложениго трсбустси привнзка к сборке, на которуго оно ссмлаетсл, CLR 
исполБзует длн поиска зтои сборки в GAC ее своиства (имн, версиго, регионалБнме 
стандартм и открмтми клгоч). Если нужнаи сборка обнаруживаетсн, возврагцаетсн 
путБ к каталогу, в котором она находитси, и загружаетси фаил с ее манифестом. 
Такои механизм поиска сборок гарантирует вмзмвагогцеи стороне, что во времн 
вмполненин будет загружена сборка издателн, создавшего ту сборку, с которои 
компилироваласБ программа. Такан гарантин возможна благодари соответствиго 
маркера открмтого клгоча, хранчгцегоси в таблице AssemblyRef ссмлагогцеиси 
сборки, открмтому клгочу из таблицм AssemblyDef сборки, на которуго ссмлагот- 
си. Если вмзмваемои сборки нет в GAC, CLR сначала игцет ее в базовом каталоге 
приложенгш, затем провернет все закрмтме пути, указаннме в конфигурационном 
фаиле приложенгш; потом, если приложение установлено при помогци MSI, CLR 
просит MSI наити нужнуго сборку. Если ни в одном из зтих вариантов сборка не 
находитси, привизка заканчиваетси неудачеи и вмдаетсн исклгочение System. 
10. FileNotFoundExceptlon. 

ПРИМЕЧАНИЕ 

Когда сборка со строгим именем загружаетса из каталога GAC, система гарантирует, 
что фаилм, содержаш,ие манифест, не подверглиси несанкционированнои модифи- 
кации. Зта проверка происходиттолико один раз назтапеустановки. Дла улучшениа 
производителвности среда CLR не проверает, 6bmn ли фаилм несанкционированно 
модифицированм, и загружает их в домен приложении с no^HbiMH правами. В то же 
времч, когда сборка со строгим именем загружаетсч не из каталога GAC, среда CLR 
проверлет фаил манифеста сборки дабн удостоверитиси в том, что он устоичив к 
несанкционированнои модификации, занимал дополнителиное времп длч проверки 
каждми раз во времч загрузки зтого фаила. 


При загрузке сборки со строгим именем не из GAC, а из другого каталога 
(базового каталога приложенгш или каталога, заданного злементом codeBase 
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в конфигурационном фаиле) CLR провернет ее хеш-кодм. Иначе говорн, в данном 
случае хеширование фаила вмполннетсл при каждом запуске приложенин. При 
зтом бмстродеиствие несколБКО снижаетсл, но можно гарантироватБ, что содер- 
жимое сборки не подверглосв несанкционированнои модификации. Обнаружив 
во времн вмполнешга несоответствие хеш-кодов, CLR вћвдает исклгочение Sy stem . 
10. FileLoadException. 


Отложенное подписание 

Ранее в зтои главе обсуждалсн способ полученгга криптографическои парм клгочеи 
при помогци утилитм SN.exe. Зта утилита генерирует клгочи, вмзмваи функции 
предоставленного Microsoft криптографического API -интерфеиса под названием 
Crypto. Полученнме в резулкгате клгочи могут сохраннтБСи в фаилах на лгобмх за- 
поминагогцих устроиствах. Например, в крупнмх организацинх (вроде Microsoft) 
генерируемме закрмтме клгочи хранитсл на аппаратнмх устроиствах в сеифах, 
и лишб несколБКО человек из штата компании имегот доступ к закрмтмм клгочам. 
Зти мерм предосторожности предотврагцагот компрометациго закрмтого клгоча 
и обеспечивагот его целостностг>. Ну, а открБгтћш клгоч, естественно, обгцедоступен 
и распространиетси свободно. 

Подготовившисб к компоновке сборки со строгим именем, надо подписатв ее 
закрБгтБгм клгочом. Однако при разработке и тестировании сборкгг оченв неудоб- 
но то и дело доставатБ закрБгтБш клгоч, которкги хранитсл «за семБго печатлми», 
позтому ,NET Framework поддерживает отложенное подписание (delayed signing), 
также ггногда назвгваемое частичним (partial signing). Отложенное подписание 
позволлет построитБ сборку с откркгтБгм клгочом компании, не требун закрнгтого 
клгоча. ОткрБгтБги клгоч дает возможностб встраггватБ в запггси таблггцвг AssemblyRef 
сборки, ссБглагогциеси на вашу сборку, получатв правилБное значение открнгтого 
клгоча, а также корректно размегцатн зти сборкгг во внутреннеи структуре GAC. 
Не подписБгван фаил закрвгтвгм клгочом, вбг полностбго лишаетесБ загцитБг от не- 
санкционированнои модификацгггг, так как пргг зтом не хешируготсн фаилвг сборкгг, 
а цггфрован подписб не вклгочаетсл в фаил. Однако на данном зтапе зто не проблема, 
посколБку подписание сборкгг откладБгваетсн лггшб на времн ее разработки, а готован 
к упаковке и развертБгваниго сборка подписБгваетсл закрвгтвгм клгочом. 

Обкгчно открнгтБги клгоч компании получагот в виде фаила и передагот его ути- 
литам, компонугогцим сборку. (Как уже отмечалосв в зтои главе, длн извлеченгга от- 
крвгтого клгоча из фаила, содержагцего пару клгочеи, можно внгзватБ утилиту SN.exe 
с параметром -р.) Следует также указатк программе построенгга сборку, подписание 
которои будет отложено, то естн ту, что будет скомпонована без закрвгтого клгоча. 
В компиллторе C# дли зтого служит параметр /delaysign. В Visual Studio в окне 
своиств проекта нужно переити на вкладку Signing гг установитБ флажок Delay sign only. 
При исполБЗОвании утилитвг AL.exe необходимо задатн параметр /delay [ sign ]. 
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Обнаружив, что подписание сборки откладмваетси, компилитор или утилита 
AL.exe генерирует в таблице метаданнмх сборки AssemblyDef записБ с открмтмм 
клгочом сборки. Как бмло сказано ранее, наличие открмтого к. поча позволиет раз- 
меститБ зту сборку в GAC, а также создаватБ другие сборки, ссБшагогциесн на нее, 
при зтом у них в записих таблицвг метаданнБгх AssembyRef будет верное значение 
открвгтого клгоча. При построении сборки в резулБтиругогцем РЕ-фаиле остаетси 
место дли цифровои подписи RSA. (Программа построенгш определнет размер не- 
обходимого свободного места, исходл из размера открвгтого клгоча.) Кстати, и на 
зтот раз хеширование содержимого фаилов не производитси. 

На зтом зтапе резулвтиругогцан сборка не имеет деиствителБнои цифровои под- 
писи. Попвгтка установки такои сборки в GAC окончитсн неудачеи, так как хеш-код 
содержимого фаила не 6бш рассчитан, что создает видимостб поврежденин фаила. 
Д./ш того чтобвг установитБ такуго сборку в GAC, нужно запретитв системе провер- 
ку целостности фаилов сборки, ввгзвав утилиту SN.exe с параметром команднои 
строки -Vr. Вбгзов SN.exe с таким параметром также ввшуждает CLR пропуститБ 
проверку хеш-кода длл всех фаилов сборки при ее загрузке во времн ввшолненгш. 
С точки зренгш внутреннеи реализации системвг параметр -Vr утилитБГ SN.exe обе- 
спечивает размегцение идентификационнои информации сборки в разделе реестра 
HKEY_LOCAL_MACHINE\SOFTWARE\Microsof l:\StrongName\Verification. 

ВНИМАНИЕ 

При исполБЗОвании лизбои утилитБ!, имекзш,еи доступ к реестру, необходимо убе- 
дитбсл в том, что длн 64-разрзднои платформБ! исполБзуетса соответствукшгал 
64-разрлднал утилита. По умолчаникз утилита под 32-разрпднукз платформу х86 
установлена в каталоге C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\ 
NETFX4.0Tools, аутилита под 64-разрпднукз платформух64— в каталоге C:\Program 
Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\x64. 


Окончателвно протестированнуго сборку надо официалвно подписатБ, что6бг 
сделатБ возможнбгми ее упаковку и развертвшание. Что6бг подписатБ сборку, снова 
вБгзовите утилиту SN.exe, но на зтот раз с параметром -R, указав имн фаила, со- 
держагцего настоигциизакрвгтБш клгоч. Параметр -R заставлнет SN.exe хешироватв 
содержимое фаила, подписатБ его закрБгтБш клгочом и встроитк цифровуго подписб 
RSA в зарезервированное свободное место. После зтого подписаннан по всем пра- 
вилам сборка готова к развертБшаниго. Не забуднте снова вклгочитб верификациго 
зтои сборки на машинах разработки и тестировангш, ввгзвав SN.exe с параметром 
-Vu или -Vx. 

Полнан последователвностБ деиствии по созданиго сборки с отложеннвш под- 
писанием вбгглидит следугогцим образом. 

1. Во времи разработки сборки следует получитв фаил, содержагции лишб от- 
крБгтБги клгоч компании, и добавитБ в строку компилиции сборки параметрвг 
/keyfile и /delaysign: 

csc /keyfile:MyCompany . PublicKey /delaysign MyAssembly.cs 
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2. После построенин сборкп надо вмполнитб показаннуго далее команду, что 6 б 1 
получитБ возможностб тестированин зтои сборки, установки ее в каталог GAC 
и компоновки других сборок, ссБшагогцихсн на нее. Зту команду достаточно 
исполнитб лишб раз, не нужно делатн зто при каждои компоновке сборки. 

SN.exe -Vr MyAssembly.dll 

3. Подготовившисб к упаковке и развертвшаншо сборки, надо получитк закрБПБш 
клгоч компании и вбшолнитб приведеннуго далее команду. При желании можно 
установитв новуго версиго в GAC, но не пвгтаитесБ зто сделатБ до вБшолненгш 
шага 4. 

SN.exe -R MyAssembly.dll МуСотрапу. PrivateKey 

4. Дли тестировангш сборки в реалБНБгх условинх снова вклгочите проверку сле- 
дугогцеи командои: 

SN -Vu MyAssembly.dll 

В начале раздела говорилосБ о хранении клгочеи организации на аппаратнБгх 
носителих, например на смарт-картах. Длл того чтобвг обеспечитв безопасностБ 
клгочеи, необходимо следитк, что 6 бг они никогда не записБгвалисБ на диск в виде 
фаилов. Криптографические проваидервг (Cryptographic Service Providers, CSP) 
операционнои системвг предоставлнгот контепнери, позволигогцие абстрагиро- 
ватБСи от физического места храненгш клгочеи. Например, Microsoft исполБзует 
CSP -проваидера, которвги при обрагцении к контеинеру считвгвает закрвгтБш клгоч 
с устроиства. 

Если пара клгочеи хранитсн в CSP -контеинере, необходимо исполвзоватв другие 
параметрБг при обрагцении к утилитам CSC.exe, AL.exe и SN.exe. При компшшции 
(CSC.exe) вместо /keyfile нужно задеиствоватв параметр /keycontainer, при 
компоновке (AL.exe) — параметр /кеупате вместо /keyfile, а при ввгзове SN.exe 
длл добавленгш закрвгтого клгоча к сборке, подписание которои бвшо отложено, — 
параметр -Rc вместо -R. SN.exe поддерживает дополнителвнБге параметрБг длл 
работБг cCSP. 

ВНИМАНИЕ 

Отложенное подписание удобно, когда необходимо вмполнитб какие-либо деиствил 
над сборкои до ее развертБ 1 ваниа. Например, может понадобитмш применитђ к сбор- 
кезаш,итнмеутилитБ 1 , модифицируклцие до неузнаваемости код. После подписанил 
сборки зто сделатБ уже не удастсп, так как хеш-код станет недеиствителБНБ 1 м. Так 
что если после компоновки сборки нужно ее загцититБ от декомпилиции или вмпол- 
нитб над неи другие деиствил, надо применити операцикз отложенного подписанил. 
В конце нужно запуститБутилиту SN.exe с параметром -R или -Rc, чтобм завершитБ 
подписание сборки и рассчитатБ все необходимБ 1 е хеш-кодБ 1 . 
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Закрмтое развертмвание сборок 
со строгими именами 

Установка сборок в каталог GAC дает песко.њко преимугцеств. GAC позволлет 
несколБКим приложениим совместно исполБЗОватБ сборки, сокрагцаи в целом 
количество обрагцении к физическои памнти. Кроме того, при помогци GAC легче 
развертмватБ новуго версшо сборки и заставитБ все приложенин исполвзоватБ новуго 
версикз сборки посредством реализации политики издателн (см. далее). GAC также 
обеспечивает совместное управление несколвкими версиими сборки. Однако GAC 
обвгчно находитсл под загцитои механизмов безопасности, позтому устанавливатв 
сборки в GAC может толбко администратор. Кроме того, установка сборки в GAC 
делает невозможнвш развертБгвание сборки просткгм копированием. 

Хотн сборки со строгими именами могут устанавливатБСн в GAC, зто вовсе не 
обнзателБно. В деиствителБности рекомендуетсн разверткшатБ сборки в GAC, толбко 
если они предназначенБг длн совместного исполБЗОвангш несколБКими приложе- 
ниими. Если сборка не предназначена дли зтого, следует развертншатБ ее закрБгто. 
Зто позволиет сохранитв возможностб установки путем «простого» копировангш 
и лучше изолирует приложение с его сборками. Кроме того, GAC не задуман как 
замена каталогу C:\Windows\System32 в качестве «обгцеи помоики» длл храненгш 
обгцих фаилов. Зто позволиет избежатв затирангш одних сборок другими путем 
установки их в разнвге каталоги, но «отведает» дополнителБное место на диске. 

ПРИМЕЧАНИЕ 

На самом деле злемент codeBase конфигурационного фаила задает URL -адрес, 
KOTopbin может ccbmaTbca на лкзбои каталог полнзователиского жесткого диска или 
на адрес в Web. В случае веб-адреса CLR автоматически загрузит указаннии фаил 
и сохранит его в кзше загрузки на полизователвском жестком диске (в подкаталоге 
C:\Documentsand Settings\<UserName>\Local Settings\ApplicationData\Assembly, где 
<UserName> — имл учетнои записи полизователл, вошедшего в систему). В далинеи- 
шем при ссилке на зту сборку CLR сверит метку времени локалиного фаила и фаила 
по указанному URL -адресу. Если последнии новее, CLR загрузит фаил толвко раз (зто 
сделано длл повмшенил производителиности). Пример конфигурационного фаила 
с злементом codeBase будет продемонстрирован позже. 


Помимо развертБшангш в GAC или закрвгтого развертвшангш, сборки со стро- 
гими именами можно развертБшатБ в произволвном каталоге, известном лишб не- 
болБшои группе приложении. Допустим, вбг создали три приложенгш, совместно 
исполБзугогцие одну и ту же сборку со строгим именем. После установки можно 
создатв по одному каталогу дли каждого приложешш и дополнителБНБш каталог 
дли совместно исполвзуемои сборки. При установке приложении в их каталоги 
также записБшаетси конфигурационнБпг ХМЕ-фаил, а в злемент codeBase длл со- 
вместно исполБзуемои сборки заноситси путн к неи. В резулнтате при вБгполнении 


Как исполнлкнцал среда разрешает сснлки на типм 111 


CLR будет знатБ, что совместно исполБзуемуго сборку надо искатБ в каталоге, со- 
держагцем сборку со строгим именем. Учтите, что зтот способ применнетсл доволбно 
редко и в силу рнда причин не рекомендуетсн. Дело в том, что в таком сценарии ни 
одно отделБно взитое приложение не в состоинии определитћ, когда именно нужно 
удалитБ фаилБ! совместно исполвзуемои сборки. 


Как исполн^к) 1 да^ среда разрешает 

ССБШКИ На ТИПБ1 

В начале главБ1 2 вб 1 видели следуклции исходнбп! текст: 

public sealed class Program { 
public static void Main() { 

System.Console.WriteLine("Hi"); 

} 

} 

Допустим, в резулвтате компилнции и построенин зтого кода получиласБ сборка 
Program.exe. При запуске приложенгш происходит загрузкаи инициализацгш CLR. 
Затем CLR сканирует CLR -заголовок сборки в поисках атрибута MethodDef Token, 
идентифициругогцего метод Main, представлигогции точку входа в приложение. 
CLR находит в таблице метаданнвгх MethodDef смегцение, по которому в фаиле на- 
ходитсл IL -код зтого метода, и компилирует его в магниннБш код процессора при 
помогци JIT -компилнтора. Зтот процесс вклгочает в себн проверку безопасности 
типов в компилируемом коде, после чего начинаетсл исполнение полученного ма- 
шинного кода. Далее показан IL -код метода Main. Чтобвг получитв его, и запустил 
ILDasm.exe, внгбрал в менго View команду Show Bytes и дваждвг гцелкнул на методе 
Main в дереве просмотра. 

.method public hidebysig static void Main() cil managed 
// SIG: 00 00 01 
{ 

.entrypoint 

// Method begins at RVA 0x2050 
// Code size 11 (0xb) 

.maxstack 8 

IL_0000: /* 72 I (70)000001 */ 

ldstr "Hi" 

IL_0005: /* 28 | (0A)000003 */ 

call void [mscorlib]System.Console::WriteLine(string) 

IL_00@a: /* 2A | */ 

ret 

} // end of method Program::Main 

Bo времи JIT -компилнцгш зтого кода CLR обнаруживает все ссбглки на типбг 
и членБг и загружает сборки, в которвгх они определенБг (если они егце не загру- 
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женм). Как видите, показаннми код содержит ссмлку на метод System.Console. 
Wnlte-Line: команда Call ссмлаетсн на маркер метаданнмх 0А000003. Зтот маркер 
идентифицирует записБ 3 таблицм метаданнмх MemberRef (таблица 0А). Просма- 
триван зту записБ, CLR видит, что одно из ее полеи ссмлаетсл на злемент таблицм 
TypeRef (описмвакнции тип System . Console). ЗаписБ таблицм TypeRef направлиет 
CLR к следукнцеи записи в таблице AssemblyRef: 

MSCorLib, Version=4. 0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 

Ha зтом зтапе CLR уже знает, какаи сборка нужна, и еи остаетсн .iiiiiii, наити 
и загрузитБ зту сборку. 

При разрешении ссбшки на тип CLR может наити нужнБпг тип в одном из трех 
мест. 

□ В том же фаиле. Обрапктшс к типу, расположенному в том же фаиле, определл- 
етсл при компилиции (даннвш процесс иногда назншакзт ранним свлзиванием). 
Тип загружаетсн прнмо из зтого фаила, и исполнение продолжаетси. 

□ В другом фаиле тои же сборки. Исполннкицал среда провериет, что фаил, на 
которвш ccbi.TaiOTOi, описан в таблице FileRef в манифесте текугцеи сборки. 
При зтом nciio.TiiMioinaa среда игцет его в каталоге, откуда 6 бш загружен фаил, 
содержагции манифест сборки. Фаил загружаетсн, провериетси его хеш-код, 
что 6 б 1 гарантироватБ его целостностБ, затем CLR находит в нем нужнвш член 
типа, и исполнение продолжаетси. 

□ В фаиле другои сборки. Когда тип, на которнш ссБшаготси, находитси в фаиле 
другои сборки, исполннгогцаи среда загружает фаил с манифестом зтои сборки. 
Если в фаиле с манифестом необходимого типа нет, загружаетсн соответствугогции 
фаил, CLR находит в нем нужнвш член типа, и исполнение продолжаетси. 

ПРИМЕЧАНИЕ 

ТаблицБ! метаданннх ModuleDef , ModuleRef и FileDef ссмла 1 отс 0 на фаилм по имени 
и расширеник). Однако таблица метаданнБ 1 х AssemblyRef ссмлаетсл на сборки толбко 
по имени, без расширении. Во времн привизки ксборке система автоматически до- 
бавллет к имени фаила расширение DLL или ЕХЕ, пмталсБ наити фаил путем проверки 
каталогов по алгоритму, описанному в главе 2. 

Если во времи разрешенгш ссбшки на тип возникагот ошибки (не удаетсн наити 
или загрузитв фаил, не совпадает значение хеш-кода и т. п.), ввгдаетсн соответ- 
ствугогцее исклгочение. 

ПРИМЕЧАНИЕ 

При желании можно зарегистрироваш в вашем коде методм обратного вм- 
зова с собБ 1 типми из System.AppDomain.AssemblyResolve, System.AppDomain. 
ReflectionOnlyAssemblyRessolve и System.AppDomain. TypeResolve. B методахобрат- 
ного вмзова Bbi можете вмполниљ программни1и код, KOTopbiti решает зту проблему 
и позволпет приложеникз вмполнптвсп без вмбрасв 1 ванип исклкзченип. 
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В предмдушем примере среда CLR обнаруживала, что тип System . Console реа- 
лизован в фаиле другои сборки. CLR должна наити зту сборку и загрузитБ РЕ-фаил, 
содержагции ее манифест. После зтого манифест сканируетсл в поисках сведении 
о РЕ-фаиле, в котором реализован искомми тип. Если необходимми тип содержитсн 
в том же фаиле, что и манифест, все замечателћно, а если в другом фаиле, то CLR 
загружает зтот фаил и просматривает его метаданнме в поисках нужного типа. 
После зтого CLR создает cboio внутреннкио структуру даннмх длл представленгш 
типа и JIT -компилнтор завершает компилнцшо метода Main. В завершение процесса 
начинаетсл исполнение метода Main. 

Рисунок 3.2 иллгострирует процесс привизки к типам. 



Рис. 3.2. Блок-схема алгоритма поиска метаданних, исполвзуеммх CLR, фаила сборки, 
где определен тип или метод, на коториш ссмлаетсл IL -код 


Если какаи-либо операции заканчиваетсн неудачеи, то вмдаетсн соответствуго- 
гцее исклгочение. 

Естб егце один нгоанс: CLR идентифицирует все сборки по имени, версии, регио- 
налБному стандарту и открБггому клгочу. Однако GAC различает сборки по имени, 
версии, регионалБному стандарту, открБггому клгочу и процессорнои архитектуре. 
При поиске сборки в GAC среда CLR ввшснлет, в каком процессе ввшолннетсн при- 
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ложение — 32-разрндном х86 (возможно, с исполБЗОванием технологии WoW64), 
64-разридном х64 или 64-разридном ARM. Сначала вмполниетсл поиск сборки 
в GAC с учетом процессорнои архитектурм. В случае неудачи происходит поиск 
сборки без учета процессорнои архитектурм. 

ВНИМАНИЕ 

Строго говорл, приведеннми пример не пвлаетса стопроцентно вернмм. Длл ссмлок 
на методм и типм, определеннме в сборке, не поставллемои в составе .NET Framework, 
все сказанное верно. Однако сборки .NET Framework(BTOM числе MSCorLib.dll) тесно 
свлзанв 1 с работакнцеи версиеи CLR. Лкзбал сборка, ссмлакнцалсл на сборки .NET 
Framework, всегда привлзмваетсл к соответствукнцеи версии CLR. Зтот процесс на- 
змвакзт унификациеи (unification), и Microsoft его поддерживает, потому что в зтои 
компании все сборки .NET Ргате^огктестирукзтсасконкретнои версиеи CLR. Позтому 
унификацил стека кода гарантирует корректнукз работу приложении. 

В предмдуидем примере ссмлка на метод VVriteLine обнекта System.Console привл- 
змваетсл кверсии MSCorLib.dll, соответствукнцеи версии CLR, независимо оттого, 
на какуго версикз MSCorLib.dll ссмлаетсл таблица AssemblyRef в метаданнмх сборки. 


Из зтого раздела мм узнали, как CLR игцет сборки, когда деиствует политика, 
предлагаемаи по умолчашпо. Однако администратор или и.здатслг, сборки может 
заменитћ зту политику. Способу измененгш политики привлзки CLR по умолчашпо 
посвишенм следугондие два раздела. 

ПРИМЕЧАНИЕ 

CLR поддерживает возможности перемешенил типа (класса, структурм, пере- 
числимого типа, интерфеиса или делегата) из однои сборки в другукх Например, 
в .NET 3.5 класс System.TimeZonelnfo определен в сборке System.Core.dll. Но в .NET 
4.0 компанил Microsoft переместила зтот класс в сборку MsCorLib.dll. В стандартнои 
ситуации перемешениетипа из однои сборки в другук) нарушает работу приложенич. 
Однако CLR предлагает восполвзоваљсл атрибутом System.Runtime.CompilerServices. 
TypeForwardedToAttribute, KOTopbin применлетсп в оригиналинои сборке (напри- 
мер, System.Core.dll). Конструктору атрибута передаетсл параметр типа System. 
Туре. Он обозначает новми тип (которми тепери определеннми в MSCorLib.dll), ко- 
торми тепери должно исполнзовати приложение. С того момента, как конструктор 
TypeForwardedToAttribute принимает зтот тип, содержаидач его сборка будет зависељ 
от сборки, в которои он определен. 

Если вм воспол^зуетес^ зтим преимушеством, нужно также применити атрибут 
System.Runtime.CompilerServices.TypeForwardedToAttribute в новои сборке и указатв 
конструктору атрибута полное имч сборки, которал служит длл определенич типа. 
Зтот атрибут o6bi4HO исполизуетсп длл инструменталинмх средств, утилит и сериа- 
лизации. Как толико конструктор TypeForwardedToAttribute получает строку с зтим 
именем, сборка, содержашаи зтот атрибут, становитсл независимои от сборки, 
определлкзшеи тип. 
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ДополнителБнне административнБ1е 
средства (конфигурационнме фаилм) 

В разделе «Простое средство администрировашш (конфигурационнми фаил)» гла- 
вм 2 мм кратко познакомилисБ со способами измененил администратором алгоритма 
поиска и привнзки к сборкам, исполБзуемого CLR. В том же разделе н показал, как 
перемегцатБ фаи.њ1 сборки, на которуго ссБшаготсл, в подкаталог базового каталога 
приложенин и как CLR исполвзует конфигурационнБпг XМ L-(})aii.i приложенгш 
длл поиска перемегценшлх фаилов. 

Посколвку в главе 2 обсуждалсн лишб атрибут privatePath злемента probing, 
здесБ мб 1 рассмотрим осталБНБге злементБг конфигурационного ХМД-фаила: 

<?xml version="1.0"?> 

<configuration> 

<runtime> 

<assemblyBinding xmlns="urn:schemasmicrosoftcom:asm.vl"> 

<probing privatePath="AuxFiles;bin\subdir" /> 

<dependentAssembly> 

<assemblyldentity name="SomeClassLibrary" 

publicKeyToken="32ab4ba45e0a69al" culture="neutral"/> 

<bindingRedirect 

oldVersion="l.0.0.0" newVersion="2.0.0.0" /> 

<codeBase version="2.0.0.0" 

href="http://www.Wintellect.com/SomeClassLibrary.dll" /> 

</dependentAssembly> 

<dependentAssembly> 

<assemblyldentity name="TypeLib" 

publicKeyToken="lf2e74e897abbcfe" culture="neutral"/> 

<bindingRedirect 

oldVersion="3.0.0.03.5.0.0" newVersion="4.0.0.0" /> 

<publisherPolicy apply="no" /> 

</dependentAssembly> 

</assemblyBinding> 

</ runtime> 

</configuration> 

ХМ L -фаил предоставлиет CLR обширнуго информациго. 

□ Злемент probing. Определлет поиск в подкаталогах AuxFiles и bin\subdir, располо- 
женнБгх в базовом каталоге приложенгш, при попвгтке наити сборку с нестрогим 



116 Глава 3. Совместно Mcnoab3yeMbie сборки и сборки со строгим именем 


именем. Сборки со строгим именем игцутсл в GAC или по URL -адресу, указан- 
ному злементом codeBase. CLR ишет сборки со строгим именем в закрмтмх 
каталогах приложентш толгжо в том случае, если злемент codeBase не указан. 

□ Первми набор злементов dependentAssembly, assemblyldentity и binding- 
Redirect. При попмтке наити сборки SomeClassLibrary с номером версии 
1.0.0.0 и неитралБнмми регионалБнмми стандартами, изданнме организациеи, 
владегогцеи открмтмм клгочом с маркером 32ab4ba45e0a69al, система вместо 
зтого будет искатБ аналогичнуго сборку, но с номером версии 2.0.0.0. 

□ Злемент codebase. При попмтке наити сборку SomeClassLibrary с номером 
версии 2.0.0.0 и неитралБнмми регионалБнмми стандартами, изданнуго организа- 
циеи, владегогцеи открмтмм клгочом с маркером 32ab4ba45e0a69al, система будет 
пмтатБСн вмполнитб привнзку по адресу, заданному в URL: http://wwwWintellect. 
com/SomeClassLibrary.dll. Хотн н и не говорил об зтом в главе 2, злемент codeBase 
можно применнтБ и к сборкам с нестрогими именами. При зтом номер версии 
сборки игнорируетсл и его следует опуститБ при определении злемента codeBase. 
URL -адрес, заданнБги злементом codeBase, должен ссБшатБСл на подкаталог 
базового каталога приложенгш. 

□ Второи набор злементов dependentAssembly, assemblyldentity и binding- 
Redirect. При попвгтке наити сборку TypeLib с номерами версии от 3.0.0.0 до 
3.5.0.0 вклгочителБно и неитралБНБши регионалБНБши стандартами, изданнуго 
организациеи, владегогцеи открвгтвш клгочом с маркером If2e74e897abbcfe, 
система будет искатк версиго 4.0.0.0 Toii же сборки. 

□ Злемент publisherPolicy. Если организацин, производителв сборки TypeLib, 
развернула фаил политики издатели (описание зтого фаила см. в следуготем 
разделе), среда CLR должна игнорироватв зтот фаил. 

При компилиции метода CLR определлет типбг и членБг, на которнге он ссбг- 
лаетси. ИсполБзун зти даннБге, исполннгогцан среда определлет (путем просмотра 
таблицБг AssemblyRef вБгзБгвагогцеи сборки), на какуго сборку исходно ссвшаласБ 
вБгзБшагогцаи сборка во времн компоновки. Затем CLR игцет сведенгш о сборке 
в конфигурационном фаиле приложенгш и следует лгобвгм измененгшм номера 
версии, заданнвш в зтом фаиле. 

Если значение атрибута apply злемента publisherPolicy равно yes или от- 
сутствует, CLR проверлет наличие в GAC новои сборки/версии и примениет все 
перенаправленгш, которвге счел необходимвш указатБ издателБ сборки (о политике 
издателл рассказБшаетсл в следугогцем разделе); далее CLR игцет именно зту сбор- 
ку/версиго. Наконец CLR просматривает сборку/версиго в фаиле Machine.config 
и применнет все указаннвге в нем перенаправленгш к другим версгшм. 

На зтом зтапе среда CLR знает номер версии сборки, которуго она должна за- 
грузитв, и пБгтаетсл загрузитБ соответствугогцуго сборку из GAC. Если сборки в GAC 
нет, а злемент codeBase не определен, CLR пвгтаетсл наити сборку, как описано 
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в главе 2. Если конфигурационнми фаил, задагогции последнее изменение номера 
версии, содержит злемент codeBase, CLR пмтаетсл загрузитБ сборку с URL -адреса, 
заданного зти.м злементом. 

Зти конфигурационнв 1 е фаилм обеспечивагот администратору настонгции 
контролБ над решением, принимаеммм CLR отпоситс.њпо загрузки тои или инои 
сборки. Если в приложении обнаруживаетсл ошибка, администратор может свн- 
затБСн с издателем сборки, содержагцеи ошибку, после чего издателБ пришлет новуго 
сборку. По умолчаниго среда CLR не может загрузитт, новуго сборку, потому что уже 
сугцествугогцан сборка не содержит ссмлки на новуго версиго. Однако администратор 
может заставитБ CLR загрузитг, новуго сборку, модифицировав конфигурационнми 
ХМД-фаил приложенгш. 

Если администратор хочет, чтобм все сборки, установленнме на компБготере, 
исполБЗОвали новуго версиго, то вместо конфигурационного фаила приложенгш 
он может модифицироватБ фаил Machine.config дли данного компБготера, и CLR 
будет загружатБ новуго версиго сборки при каждои ссвглке из приложении на ста- 
руго версиго. 

Если в новои версии стараи ошибка не исправлена, администратор может уда- 
литб из конфигурационного фаила строки, определлгогцие исполБЗОвание зтои 
сборки, и приложение станет работатв, как ранкше. Важно, что система позволиет 
исполвзоватБ сборку с версиеи, отличнои от указаннои в метаданнвгх. Такан до- 
полнителБнан гибкостБ оченБ удобна. 

Управление версивми при помо!ци политики издателл 

В ситуации, описаннои в предвгдугцем разделе, издателБ сборки просто присБшал 
новуго версиго сборки администратору, которвш устанавливал сборку и вручнуго 
редактировал конфигурационнвге ХМЕ-фаилБ 1 машинБг или приложенгш. Вообгце 
говорн, после исправленгш ошибки в сборке издателго понадобитсл простои меха- 
низм упаковки и распространенгш новои сборки по всем полБЗОвателлм. Кроме 
того, нужно как-то заставитв среду CLR каждого полБЗОвателл задеиствоватв 
новуго версиго сборки вместо старои. Естественно, каждвги полБЗОвателБ может 
сам изменитБ конфигурационнБге ХМЕ-фаилБ 1 на своих машинах, но зтот способ 
краине неудобен и ненадежен. Издателго нужен механизм, которвш позволил 6 бг 
ему определитБ свого <<политику» и установитв ее на полБЗОвателБСКгш компкготер 
с новои сборкои. В зтом разделе показано, как издателв сборки может создатк по- 
добнуго политику. 

Допустим, вб 1 — издателБ, толбко что создавшии новуго версиго своеи сборки, 
в которои исправлено несколвко ошибок. УпаковБшан новуго сборку длл рассвшки 
полБЗОвателнм, надо создатв конфигурационнБпг ХМЕ-фаил. Он оченн похож на те, 
что мб 1 обсуждали ранБше. Вот пример конфигурационного фаила SomeClassLibrary. 
config длл сборки SomeClassLibrary.dll: 

<configuration> 

<runtime> 

продолжение & 
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<assemblyBinding xmlns="unn : schemasmicrosoftcom:asm.vl"> 

<dependentAssembly> 

<assemblyldentity name="SomeClassLibnary" 

publicKeyToken="32ab4ba45e0a69al" culture="neutral"/> 

<bindingRedirect 

oldVersion="l.0.0.0" newVersion="2.0.0.0" /> 

<codeBase version="2.0.0.0" 

href="http://www.Wintellect.com/SomeClassLibrary.dll"/> 

</dependentAssembly> 

</assemblyBinding> 

</runtime> 

</configuration> 

Конечно, издателБ может определнтБ политику толбко длн своих сборок. Кроме 
того, показаннБге здесБ злементБ1 — единственнБге, которБШ можно задатн в конфи- 
гурационном фаиле политики издателл. Например, в конфигурационном фаиле 
политики нелБЗн задаватБ злементБ1 probing и publisherPolicy. 

Зтот конфигурационнБпт фаил заставллет CLR при каждои ссвшке на версшо 
1.0.0.0 сборки SomeClassLibrary загружатв вместо нее версшо 2.0.0.0. Теперв bbi, как 
издателв, можете создатБ сборку, содержагцуго конфигурационнБп! фаил политики 
издателл. Дли создании сборки с политикои издателл вБ13Б1ваетсл утилита AL.exe 
со следугогцими параметрами: 

AL.exe /out : Policy. 1.0. SomeClassLibrary.dll 
/version :1.0.0.0 
/keyfile:MyCompany . snk 
/linkresource:SomeClassLibrary.config 

Ниже приведенБ1 краткие описанин параметров команднои строки AL.exe. 

□ Параметр /out приказвшает AL.exe создатБ новб 1 и РЕ-фаил с именем 
Policy. 1. 0.SomeClassLibrary.dll, в котором нет ничего, кроме манифеста. Имн зтои 
сборки имеет оченв болБшое значение. Перван частв имени, Policy, сообгцает 
CLR, что сборка содержит информациго политики издателл. Втораи и третнл 
части имени, 1.0, сообгцагот CLR, что зта политика издателн предназначена длн 
лгобои версии сборки SomeClassLibrary, у которои старшии и младшии номера 
версии равнБ 1 1.0. Политики издателл применнготсн толбко к старшему и млад- 
шему номерам версии сборки; нелвзн создатБ политику издателн длн отделБНБ1х 
построении или редакции сборки. Четвертал частв имени, SomeClassLibrary, 
указБшает имн сборки, которои соответствует политика издателл. Плтаи и по- 
следнин частв имени, dll, — зто просто расширение, данное резулБтиругогцему 
фаилу сборки. 

□ Параметр /version идентифицирует версиго сборки с политикои издателн, 
которан не имеет ничего обгцего с версиеи самои сборки. Как видите, версинми 
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сборок, содержаших политику издателн, тоже можно управлнтћ. Сеичас издате- 
лк) нужно создатБ политику, перенаправликзшук) CLR от версии 1.0.0.0 сборки 
SomeClassLibrary к версии 2.0.0.0, а в будушем может потребоватБСи политика, 
перенаправлнЈОшаи от версии 1.0.0.0 сборки SomeClassLibrary к версии 2.5.0.0. 
CLR исполћзует номер версии, заданнми зтим параметром, чтобм вмбратћ самуго 
последнгок) версиго сборки с политикои издателл. 

□ Параметр /keyf ile заставлиет AL.exe подписатБ сборку с политикои издателн 
при помоти napbi клгочеи, принадлежашеи издателго. Зта пара клгочеи также 
должна совпадатћ с iiapoii, исполБЗОваннои длл подписанин всех версии сбор- 
ки SomeClassLibrary. В конце концов, именно зто совпадение позволиет CLR 
установитћ, что сборка SomeClassLibrary и фаил с политикои издателн длн зтои 
сборки созданБ1 одним издателем. 

□ Параметр /linkresource заставлпет AL.exe считатБ конфигурационнБ1и 
ХМ L -фаил отделБНБш фаилом сборки. При зтом в резулБтате компоновки 
получаетси сборка из двух фаилов. Оба следует упаковБшатБ и развертБшатБ 
на полБЗОвателБСКих компБГОтерах с новои версиеи сборки SomeClassLibrary. 
Между прочим, конфигурационнБП! ХМ L -фаил нелБЗи встраиватБ в сборку, вбк 
ЗБшан AL.exe с параметром /embedresource, и создаватБ таким образом сборку 
из одного фаила — CLR требует, что 6 б 1 сведении о конфигурации в формате 
XML размегцалисБ в отделБном фаиле. 

Сборку, скомпонованнуго с политикои издатели, можно упаковатБ с фаилом 
новои версии сборки SomeClassLibrary.dll и передатв полБЗОвателлм. Сборка с по- 
литикои издатели должна устанавливатБСн в GAC. Саму сборку SomeClassLibrary 
можно установитБ в GAC, но зто не обизателвно. Ее можно развернутБ в базовом 
каталоге приложенин или в другом каталоге, заданном в URL -адресе из злемента 
codeBase. 

ВНИМАНИЕ 

ИздателБ должен создаватБ сборку со своеи политикои лишб длл развертБ 1 ванил 
исправленнои версии сборки или пакетов исправлении длл нее. Установка нового 
приложенил не должна требоватБ сборки с политикои издателл. 


И последнее о политике издателл. Допустим, издателв распространил сборку 
с политикои издателн, но в новои сборке почему-либо оказалосБ болБше новбгх оши- 
бок, чем исправлено старБгх. В зтом случае администратору необходимо, что6бг CLR 
игнорировала сборку с политикои издателн. Длл зтого он может отредактироватБ 
конфигурационнБп! фаил приложенин, добавив в него злемент publisherPolicy: 

<publisherPolicy apply="no"/> 

Зтот злемент можно разместитБ в конфигурационном фаиле приложенгш как 
дочернии по отношениго к злементу <assemblyBinding> — в зтом случае он при- 
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мепметсм ко всем его сборкам. Если злемент размегцаетсн как дочернии по отно- 
шениго к <dependantAssembly>, он применнетси к отде./њпои сборке. Обрабатмван 
конфигурационнми фаил приложенгш, CLR «видит», что не следует искатБ в GAC 
сборку с политикои издателн, и продолжает работатБ с более старои версиеи сбор- 
ки. Однако замечу, что CLR все равно провернет и применнет лкзбуго политику, 
заданнуго в фаиле Machine.config. 

ВНИМАНИЕ 

ИсполБЗОвание сборки с политикои издателл фактически лвллетсл залвлением из- 
дателл о совместимости разнмх версии сборки. Если новал версил несовместима 
с более раннеи версиеи, издателБ не должен создаватБ сборку с политикои издате- 
лл. Вообиде, следует исполБЗОватБ сборки с политикои издателл, если компонуетсл 
новал версил с исправленилми ошибок. Новукз версикз сборки нужно протестиро- 
ватБ на обратнук) совместимостм В то же времл, если к сборке добавллкзтса HOBbie 
функции, следует подумати о том, чтобм отказатисч от свчзи с прежними сборками 
и от применении сборки с политикои издателл. Кроме того, в зтом случае отпадет 
необходимости тестированил на обратнукз совместимости. 
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Глава 4. Основм типов 


В зтои главе представленм основнме принципм исполБЗОванин типов и обгцензмко- 
вои исполннкнцеи средм (Common Language Runtime, CLR). B частности, мм рас- 
смотрим минималћнук) функционалћностБ, присугцук) всем типам, и такие вопросм, 
как контролБ типов, пространства имен, сборки и различнме способм приведении 
типов обвектов. В конце главм н о6ђнсннк>, как во времн вмполненгш взаимодеи- 
ствугот друг с другом типм, обвектм, стеки потоков и управлнеман куча. 


Все Tnnbi — производнме от System.Object 

В CLR каждми обвект примо или косвенно ивлиетсл производнмм от System. 
Object. Зто значит, что следугогцие определенин типов идентичнм: 

// Тип, нелвно производнми от Object 
class Employee { 

} 

// Тип, ввно производнми от Object 
class Employee : System.Object { 

} 

Благодарн тому, что все типм, в конечном счете, нвлнготси производнмми от 
System.Object, лгобои обвект лгобого типа гарантированно имеет минималћнми 
набор методов. Открмтме зкземплирнме методм класса System.Object перечис- 
ленм в табл. 4.1. 


Таблица 4.1. Открмтме методм System.Object 


Открмтми метод 

Описание 

Equals 

Возвратает true, если два обвекта имегот одинаковБге значенил. 
Подробнее об зтом методе рассказвгваетсл в разделе «Равенство 
и тождество обвектов» главв1 5 

GetHashCode 

Возвратает хеш-код длл значенил данного обЂекта. Зтот метод 
следует переопределитв, если обвектв! типа исполвзуготсн в каче- 
стве клгоча хеш-таблиц. Вообте говорл, класс Object вв1бран длл 
разметенин зтого метода неудачно, потому что болвшинство типов 
не исполвзуетсл в качестве клгочеи хеш-таблиц; зтот метод умест- 
нее бнло бш определитБ в интерфеисе. Подробнее об зтом методе 
рассказв!ваетсл в разделе «Хеш-кодБ1 обБектов» главв! 5 
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Открмтми метод 

Описание 

ToString 

По умолчаншо возвравдает полное имл типа (this.GetType(). 
FullName). Fla практике зтот метод переопределлгот, чтобвг он 
возвратцал обвект String, содержагции состолние обвекта в виде 
строки. FianpiiMep, переопределеннвге методв 1 длл таких фунда- 
менталвнБ 1 х типов, как Boolean и Int32, возврагцагот значенил 
обвектов в строковом виде. Кроме того, к переопределеншо мето- 
да часто прибегакзт при отладке: вб1зов такого метода возврагцает 
строку, содержагцук) значеш-ш полеи обвекта. Предполагаетсл, 
что ToString учитБ 1 вает информацшо Culturelnfo, свлзаннук) с bbi- 
ЗБшаклцим потоком. Подробнее о методе ToString рассказБшаетсл 
в главе 14 

GetType 

Возврагцает зкземпллр обвекта, производного от Туре, которви! 
идентифицирует тип обвекта, вБгзвавшего GetType. Возврагцаемвп! 
обвект Туре может исполБзоватБсн с классами, реализукнцими от- 
ражение длн полученил информации о типе в виде метаданнБ1х. 
Отражение рассматриваетсн в главе 23. Метод GetType невирту- 
алБНБги, его нелБзн переопределитБ, позтому классу не удастсн 
исказитБ сведенил о своем типе; таким образом обеспечиваетсл 
безопасноств типов 


Кроме того, типам, производнмм от System.Object, доступнм некоторме за- 
гцигценнме методм (табл. 4.2). 


Таблица 4.2. 3amnmeHHbie методм System.Object 


Заидииденнши 

метод 

Описание 

Memberwise- 

Clone 

Зтот невиртуалБНБ1и метод создает новбги зкземпллр типа и при- 
сваивает поллм нового обвекта соответствукшџге значенин обвекта 
this. Возврагцаетсл ссвшка на созданнБги зкземплнр 

Finalize 

Зтот виртуалБНБП! метод вБ13Б1ваетсл, когда уборшик мусора опре- 
деллет, что обвект лвллетсл мусором, но до возврагценил занлтои 
обвектом памнти в кучу. В типах, требукицих очистки при сборке 
мусора, следует переопределитв зтот метод. Подробнее о нем см. 
главу 21 


CLR требует, чтобм все обвектм создавалисв оператором new. Например, обвект 
Employee создаетсл следугошим образом: 

Employee е = new Employee("ConstructorParaml"); 

Оператор new вмполннет следугогцие деиствин: 
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1. Вмчисление количества баитов, необходиммх длл храненин всех зкземплир- 
нмх полеи типа и всех его базовмх типов, вклкзчаи System.Object (в котором 
отсутствугот собственнме зкземплнрнме полн). Кроме того, в каждом обвекте 
кучи должнм присутствоватБ дополнителБнме членБ1, назБшаемБге указателем 
на обђект-тип (type object pointer) и индексом блока синхронизации (sync block 
index); они необходимБ 1 CLR длл управленгш обвектом. Баитв 1 зтих дополни- 
телвнБ1х членов добавлнготсл к баитам, необходимвш дли размегценгш самого 
обвекта. 

2. ВБгделение памнти длн обвекта с резервированием необходимого дли данного 
типа количества баитов в управлнемои куче. ВвгделеннБге баитБ 1 инициализи- 
руготсл нулнми (0). 

3. Инициализацин указателл на обвект-тип и индекса блока синхронизации. 

4. Вбгзов конструктора зкземплира типа с параметрами, указаннвши при вБгзове 
new (в предБгдугцем примере зто строка ConstructorParaml). Болбшинство 
компилнторов автоматически вклгочает в конструктор код ввгзова конструктора 
базового класса. Каждвпг конструктор вБшолннет инициализациго определеннБгх 
в соответствугогцем типе полеи. В частности, вБгзвшаетсл конструктор System. 
Object, но он ничего не делает и просто возврагцает управление. 

Вбшолнив все зти операции, new возврагцает ссвшку (или указателк) на вновб 
созданнБпг обвект. В предБгдугцем примере кода зта ссБглка сохраниетсл в пере- 
меннои е типа Employee. 

Кстатгг, у оператора new нет парвг — оператора delete, то еств нет нвного способа 
освобожденин памнти, занитои обвектом. Уборкои мусора занимаетсл среда CLR 
(см. главу 21), которан автоматически находит обвектБг, ставшие ненужнвгми или 
недоступнБгми, и освобождает занимаемуго ими памлтв. 


Приведение типов 

Одна ггз важнеиших особенностеи CLR — безопасностЂ типов (type safety). Во времл 
вБгполненггн программнг среде CLR всегда известен тип обкекта. Программист всегда 
может точно определитв тип обвекта пргг помогци метода GetType. Посколкку зто 
невиртуалБНБги метод, никакои тип не сможет сообгцитБ о себе ложнБге сведенин. 
Например, тггп Employee не может переопределитБ метод GetType, что6бг тот вернул 
тип SuperHero. 

Пргг разработке программ часто прггбегагот к прггведенггго обкекта к другггм тггпам. 
CLR разрешает прггвести тип обвекта к его собственному типу гглгг лгобому из его 
базоввгх тггпов. В каждом нзвгке программировангш прггведенгге типов реалггзова- 
но по-своему. Например, в C# нет специалвного сггнтаксиса длн прггведенггн типа 
обвекта к его базовому типу, посколвку такое прггведенгге считаетсл безопаснвгм 
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неивнмм преобразованием. Однако длм приведенин типа к производному от него 
типу разработчик на C# должен ввести операцшо нвного приведенгш типов — не- 
нвное преобразование приведет к ошибке. Следугогции пример демонстрирует 
приведение к базовому и производному типам: 

// Зтот тип непвно наследует от типа System.Object 
internal class Employee { 

} 

public sealed class Program { 
public static void Main() { 

// Приведение типа не требуетспЈ т. к. new возврашает обћект Employeej 
// а Object - зто базовни тип длп Employee. 

Object о = new Employee(); 

// Приведение типа облзателвноЈ т. к. Employee - производнми от Object 
// В других лзмках (таких как Visual Basic) компилптор не потребует 
// лвного приведенил 
Employee е = (Employee) о; 

} 

} 

Зтот пример показмвает, что необходимо компилнтору длл компилнции кода. 
Tenepb посмотрим, что произоидет во времн вмполненин программм. CLR проверит 
операции приведенил, чтобм приведение типов осугцествлилосв либо к факти- 
ческому типу обвекта, либо к одному из его базовмх типов. Например, следуго- 
гции код успешно компилируетсл, но в период вмполненгш вмдает исклгочение 
InvalidCastException: 

internal class Employee { 

} 

internal class Manager : Employee { 

} 

public sealed class Program { 
public static void Main() { 

// Создаем обкект Manager и передаем его в PromoteEmployee 
// Manager ВВЛВЕТСВ производнмм от Employee, 

// позтому PromoteEmployee работает 
Manager m = new Manager(); 

PromoteEmployee(m); 

// Создаем обтаект DateTime и передаем его в PromoteEmployee 
// DateTime НЕ ВВЛВЕТСЛ производним от Employee, 

// позтому PromoteEmployee вмбрасмвает 
// исклгачение System.InvalidCastException 
DateTime newYears = new DateTime(2013, 1, 1); 

PromoteEmployee(newYears); 

} 


продолжение & 
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public static void PromoteEmployee(Object o) { 

// B зтом месте компиллтор не знает точнОј на какои тип обтаекта 

// сснлаетсн о л поатому скомпилирует атот код 

// Однако в период внполненин CLR знает, на какои тип 

// сснлаетсн обиект о (приведение типа вмполнлетсл каждми раз), 

// и провернетЈ соответствует ли тип обћекта типу Employee 

// или другому типу, производному от Employee 

Employee е = (Employee) о; 

} 

} 


Метод Main создает обЂект Manager и передает его в PromoteEmployee. Зтот 
код компилируетсн и вмполннетсл, так как тип Manager нвллетсн производнмм от 
Object, на которми рассчитан PromoteEmployee. Внутри PromoteEmployee CLR про- 
вернет, на что ссмлаетсл о — на обвект Employee или на обвект типа, производного 
от Employee. Посколђку Manager — производнми от Employee тип, CLRBbino^HHeT 
преобразование, и PromoteEmployee продолжает работу. 

После того как PromoteEmployee возврашает управление, Main создает обвект 
DateTime, которми передает в PromoteEmployee. Обвект DateTime тоже нвлнетсл про- 
изводнмм от Object, позтому код, вмзмваклции PromoteEmployee, компилируетсн 
без проблем. Но при вмполнении PromoteEmployee CLR вЂшсниет, что о ссмлаетсл 
на обвект DateTime, не нвлнклциисн ни типом Employee, ни другим типом, произ- 
воднмм от Employee. В зтот момент CLR не в состолнии вмполнитђ приведение 
типов и генерирует исклкзчение System . InvalidCastException. 

Если разрешитЂ подобное преобразование, работа с типами станет небезопас- 
нои. Последствил могут бмтл непредсказуемм: возможное аварииное завершение 
приложенил, возникновение улзвимостеи в системе загцитм, обусловленнмх воз- 
можностђк) типов вмдаватЂ себл за другие типм. ФалЂСификацил типов подвергает 
серЂезному риску устоичивостЂ работм приложении, позтому столђ присталЂное 
внимание в CLR уделлетсл безопасности типов. 

В данном примере бмло бм правилЂнее вмбратБ длл метода PromoteEmployee 
в качестве типа параметра не Ob ject, а Employee, чтобм ошибка пролвиласБ на стадии 
компиллции, а разработчику не пришлосБ 6bi ждатБ исклкзченил, что6б 1 узнатБ о сугце- 
ствовании проблемБг А обБект Ob ј ect л исполБЗОвал толбко длл того, что6б 1 показатБ, 
как обрабатБшагот операции приведенил типов компиллтор C# и среда CLR. 


Приведение типов в C# с noMombfo операторов is и as 

В C# сугцествугот другие механизмБ1 приведенгга типов. Например, оператор is 
проверлет совместимостБ обЂекта с даннБш типом, а в качестве резулБтата вБвдает 
значение типа Boolean (true или false). Оператор is никогда не генерирует ис- 
клгочение. Взглнните на следугогции код: 

Object о = new Object(); 

Boolean bl = (o is Object); // bl равно true 
Boolean b2 = (o is Employee); // b2 равно false 



Приведениетипов 127 


Дли null -ссмлок оператор is всегда возврагцает f alse, так как обвекта, тип 
которого нужно проверитБ, не сугцествует. 

ОбБшно оператор is исполћзуетсл следугогцим образом: 

if (о is Employee) { 

Employee е = (Employee) о; 

// ИсполБЗуем е внутри инструкции if 

} 

В зтом коде CLR по сути провериет тип обвекта дваждм: сначала в операторе 
is определлетсл совместимостБ о с типом Employee, а затем в теле оператора if 
анализируетсл, нвлиетсл ли о ссбшкои на Employee. КонтролБ типов в CLR укре- 
плиет безопасностћ, но при зтом приходитсл жертвоватБ производителБностБГО, 
так как среда CLR должна вбшсннтб фактическии тип обвекта, на которБпг ссбн 
лаетсн переменнаи (о), а затем провернтБ всго иерархиго наследованин на предмет 
наличии среди базовБ1х типов заданного типа (Employee). Посколбку такал схема 
встречаетсн в программировании часто, в C# предложен механизм, повБнпагогции 
зффективностБ кода с помшцкго оператора as: 

Employee е = о as Employee; 
if (е != null) { 

// Исполцзуем е внутри инструкции if 

} 

В зтом коде CLR провернет совместимостБ о с типом Employee. Если о и Employee 
совместимБц as возврагцает ненулевои указателБ на зтот обвект, а если нет — опера- 
тор as возврагцает null. ЗаметБте: оператор as заставлнет CLR верифицироватБ тип 
обвекта толбко один раз, а if лигнб сравнивает е с null — такап проверка намного 
зффективнее, чем определение типа обвекта. 

По сути, оператор as отличаетсл от оператора приведенгш типа толбко тем, 
что никогда не генерирует исклгочение. Если приведение типа невозможно, ре- 
зулБтатом ивлнетсл null. Если не сравнитБ полученнБш оператором резулБтат 
с null и попБгтатБСл работатБ с пустои ссбшкои, возникнет исклгочение System. 
NullReferenceException. Например: 

System.Object о = new Object(); // Создание обцекта Object 
Employee е = о as Employee; // Приведение о к типу Employee 
// Преобразование невиполнимо: исклтчение не возникло, но е равно null 
e.ToString(); // Обрацение к е вћвивает исклтчение NullReferenceException 

Даваите проверим, как вб1 усвоили материал. Допустим, сугцествугот описангш 
следугогцих классов: 

internal class В { // Базовии класс 

} 

internal class D : В { // Производнми класс 
} 

В первом столбце табл. 4.3 приведен код на С#. Попробуите определитБ резулБтат 
обработки зтих строк компилнтором и CLR. Если код компилируетсл и вБшолнлетсн 



128 Глава 4. OcHOBbi типов 


без ошибок, сделаите пометку в графе ОК, если произоидет ошибка компиллции — 
в графе СТЕ (compile-time еггог), а если ошибка времени вмполненгш — в графе 
RTE (run-time еггог). 


Таблица 4.3. Тест на знание контрола типов 


Оператор 

ок 

СТЕ 

RTE 

Object ol = new Object(); 

Да 



Object о2 = new В(); 

Да 



Object оЗ = new D(); 

Да 



Object o4 = оЗ; 

Да 



B bl = new B(); 

Да 



B b2 = new D(); 

Да 



D dl = new D(); 

Да 



B b3 = new Object(); 


Да 


D d2 = new Object(); 


Да 


B b4 = dl; 

Да 



D d3 = b2; 


Да 


Dd4 = (D)dl; 

Да 



D d5 = (D) b2; 

Да 



D d6 = (D) bl; 



Да 

Bb5 = (B)ol; 



Да 

B b6 = (D) b2; 

Да 




ПРИМЕЧАНИЕ 

В C# разрешено определат методн операторов преобразованил при помоиди типов, 
об зтом речи идет в разделе «Методм операторов преобразованил» главм 8. Зти ме- 
тодн Bbi3biBaiOTC^ толвко в случалх, когда имеет место приведение типов, и никогда 
не Bbi3biBaiOTca при исполвзовании операторов is и as в С#. 


Пространства имен и сборки 

Пространства имен испо./њзу 10 тси длн логическои группировки родственнмх типов, 
чтобм разработчику бмло прогце наити нужнми тггп. Например, в пространстве имен 
System.Text описанм типм длл обработки строк, а в пространстве имен System. 
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10 — типм длл вмполнентш операции ввода-вмвода. В следукнцем коде создатотсн 
обвектм System. 10. FileStneam и System.Text.StningBuilder: 

public sealed class Program { 
public static void Main() { 

System.10.FileStream fs = new System.10.FileStream(...); 
System.Text.StringBuilder sb = new System.Text.StringBuilder(); 

} 

} 


Зтому коду не хватает лаконичности — обрашенин к типам FileStream 
и StringBuilder вмгллднт слишком громоздко. К счасттло, многие компилнторм 
предоставлнгот программистам механизмм, позволнгогцие сократитБ обвем на- 
бираемого текста. Например, в компилиторе C# предусмотрена директива using. 
Следугогции код аналогичен предмдугцему: 

using System.I0; // Подставлитв префикс "System.I0" 
using System.Text; // Подставлвтв префикс "System.Text" 

public sealed class Program { 
public static void Main() { 

FileStream fs = new FileStream(...); 

StringBuilder sb = new StringBuilder(); 

} 

} 


Дли компилнтора пространство имен — простое средство, позволигогцее удли- 
нитб ими типа и сделатБ его уникалБнмм за счет добавленин к началу имени групп 
символов, разделеннмх точками. Например, в данном примере компилнтор интер- 
претирует FileStream как System. 10. FileStream, а StringBuilder — как System. 
Text.StringBuilder. 

ПрименлтБ директиву using в C# не облзателг>но, при необходимости достаточно 
ввести полное имн типа. Директива using заставлиет компиллтор C# добавлитБ 
к имени указаннми префикс, пока не будет наидено совпадение. 

ВНИМАНИЕ 

CLR ничего не знает о пространствах имен. При обрашении к какому-либо типу среде 
CLR надо предоставитв полное имл типа (а зто может бмљ деиствителвно длиннал 
строка сточками) и сборку, содержашукзописаниетипа, чтобм во времл вмполненил 
загрузитв зту сборку, наити в неи нужнв 1 и тип и оперироватв им. 


В предмдугцем примере компилитор должен гарантироватБ, что каждми упо- 
минутми в коде тип сугцествует и корректно обрабатмваетсл: вмзмваемме методм 
сутцествугот, число и типм передаваеммх аргументов указанм правилБно, значентш, 
возврагцаемме методами, обрабатмваготси надлежагцим образом и т. д. Не наидн 
тип с заданнмм именем в исходнмх фаилах и перечисленнмх сборках, компили- 
тор попмтаетсл добавитБ к именгг типа префикс System. 10 и проверит, совпадает 
ли полученное ими с сутцествуготцим типом. Если имн типа опитб не обнаружитси, 
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поиск повторнетсл с префиксом System.Text. Благодари двум директивам using, 
показаннмм ранее, и смог ограничитБСи именами FileStream и StningBuilder — 
компилнтор автоматически расшириет ссбшки до System . 10. FileStream и System . 
Collections . StringBuilder. Конечно, такои код намного прогце вводитсл, чем 
исходнбп!, да и читаетсл прогце. 

Компилитору надо сообгцитп при помогци параметра /reference (см. главБ 1 2 
и 3), в каких сборках искатв описание типа. В поисках нужного типа компилнтор 
просмотрит все известнвге ему сборки. Если подходнгцал сборка обнаруживаетсл, 
сведенин о неи и типе помегцаготсл в метаданнвге резулБтиругогцего управлиемого 
модулл. Длн того чтобвг информацгш из сборки бвгла доступна компиллтору, надо 
указатв ему сборку, в которои описанБг упоминаемБге типбг. По умолчаниго компи- 
лнтор C# автоматически просматривает сборку MSCorLib.dll, даже если она пвно не 
указана. В неи содержатсл описании всех фундаменталвнвгх FCL -типов, таких как 
Object, Int32, String и др. 

Легко догадатвсн, что такои способ обработки пространства имен чреват пробле- 
мами, если два (и более) типа с одинаковБгми именами находлтсн в разнвгх сборках. 
Microsoft настоителБно рекомендует при описании типов применнтв уникалБНБге 
имена. Но порои зто невозможно. В CLR поогцрлетсл повторное исполБЗОвание 
компонентов. Допустим, в приложенгггг имеготсн компонентвг, созданнБге в Microsoft 
и Wintellect, в которвгх еств типбг с одним названием, например Widget. Верстш 
Widget от Microsoft делает одно, а версгш от Wintellect - совершенно другое. В зтом 
случае процесс формировании имен типов становитсл неуправлнемвгм, и что6бг 
различатБ зти типбг, придетсл указпгватБ в коде их полнвге имена. При обрагцении 
к Widget от Microsoft надо исполБЗОватБ записБ Microsoft .Widget, а при сспглке 
на Widget от Wintellect — записБ Wintellect . Widget. В следугогцем коде сскглка на 
Widget неоднозначна, и компилитор C# вкгдаст сообгцение error CS0104: ' Widget ' 
is an ambiguous reference (ошибка CS0104: 'Widget' — неоднозначнан сскглка): 

using Microsoft; // Определием префикс "Microsoft." 
using Wintellect; // Определлем префикс "Wintellect." 

public sealed class Program { 
public static void Main() { 

Widget w = new Widget(); // Неоднозначнал ссмлка 

} 

} 

Длн того чтобкг избавитБСн от неоднозначности, надо нвно указатв компилнтору, 
какои зкземплнр Widget требуетсл создатк: 

using Microsoft; // Определлем приставку "Microsoft." 
using Wintellect; // Определлем приставку "Wintellect ." 

public sealed class Program { 
public static void Main() { 

Wintellect.Widget w = new Wintellect.Widget(); // Неоднозначности нет 

} 

} 
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В C# естћ етце одна форма директивБ1 using, позволикицаи создатБ псевдоним 
дли отделБного типа или пространства имен. Она удобна, если bbi намеренБ1 ис- 
полБЗОватБ несколБКО типов из пространства имен, но не хочетсл «захламлцтв» 
глобалБное пространство имен всеми исполБзуемвши типами. АлБтернативнБП! 
способ преодоленгш неоднозначности следуклции: 

using Micnosoft; // Определаем приставку "Microsoft." 
using Wintellect; // Определвем приставку "Wintellect ." 

// Имд WintellectWidget определлетсд как псевдоним длв Wintellect.Widget 
using WintellectWidget = Wintellect.Widget; 

public sealed class Pnogram { 
public static void Main() { 

WintellectWidget w = new WintellectWidget(); // Ошибки нет 

} 

} 

Зти методБ 1 устраненгш неоднозначности хороши, но иногда их недостаточно. 
ПредставБте, что компании Australian Boomerang Сотрапу (АВС) и Alaskan Boat 
Corporation (АВС) создали каждал свои тип с именем BuyProduct и собираготси 
поместитв его в соответствугогцие сборки. Не исклгочено, что обе компании созда- 
дут пространства имен АВС, в которвге и вклгочат тип BuyProduct. Длл разработки 
приложенгш, опериругогцего обоими типами, необходим механизм, позволигогции 
различатв программнБши средствами не толбко пространства имен, но и сборки. 
К счаствго, в компилнторе C# поддерживаготсн внешние псевдоними (extern aliases), 
позволпгогцие справитБСи с проблемои. Внешние псевдонимБг дагот также возмож- 
ностб обрагцатБСн к одному типу двух (или более) версии однои сборки. Подробнее 
о внешних псевдонимах см. спецификациго нзБ1ка С#. 

При проектировании типов, примениемБгх в библиотеках, которвге могут ис- 
полвзоватБСн третБими лицами, стараитесБ описБшатБ зти типб 1 в пространстве имен 
так, что 6 б 1 компилнторБ1 могли без труда преодолетБ неоднозначностБ типов. Веро- 
нтностБ конфликта заметно снизитсн, если в пространстве имен верхнего уровнп 
указвшаетсл полное, а не сокрагценное название компании. В документации .NET 
Framework SDK Microsoft исполвзует длн своих типов пространство имен Mic rosoft 
(например: Microsoft.CSharp, Microsoft.VisualBasic и Microsoft.Win32). 
Создаван пространство имен, вклгочите в код его обБпвление (на С#): 

namespace CompanyName { 

public sealed class A { // TypeDef: CompanyName.A 

} 

namespace X { 

public sealed class B { ... } // TypeDef: CompanyName.X.B 
} 

} 

B комментарии справа от обБнвленгш класса указано реалвное имн типа, которое 
компилитор поместит в таблицу метаданнБ 1 х определенгш типов — с точки зренгш 
CLR зто «настоигцее» имл типа. 
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Одни компилнторм вовсе не поддерживагот пространства имен, другие пониматот 
под зтим термином нечто иное. В C# директива namespace заставлнет компилнтор 
добавлитБ к каждому имени типа определеннуго приставку — зто избавлиет про- 
граммиста от необходимости писатБ массу лишнего кода. 

Свлзб между сборками и пространством имен 

Пространство имен и сборка (фаил, в котором реализован тип) не облзателБно 
свизанБ 1 друг с другом. В частности, различнБ 1 е типб1 , принадлежагцие одно- 
му пространству имен, могут 6 bitb реализованБ 1 в разнвгх сборках. Например, 
тип System . 10. FileStream реализован в сборке MSCorLib.dll, а тип System. 
10. FileSystemWatcher — в сборке System.dll. На самом деле, сборка System.IO.dll 
в .NET Framework даже не поставлнетсл. 

Одна сборка может содержатв типбг из разнБгх пространств имен. Например, типбг 
System.Int32 и System.Text .StringBuilder находлтсн в сборке MSCorLib.dll. 

Заглинув в документациго .NET Framework SDK, вбг обнаружите, что там четко 
обозначено пространство имен, к которому принадлежит тип, и сборка, в которои 
зтот тип реализован. Из рис. 4.1 видно, что тип ResXFileRef нвлнетсл частвго про- 
странстваимен System.Resources и реализованв сборке System.Windows . Forms . 
dll. Длл того чтобвг скомпилироватБ код, ссБшагогциисн на тип ResXFileRef, не- 
обходимо добавитБ директиву using System. Resources и исполвзоватБ параметр 
компилнтора / г :System.Windows .forms .dll. 
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Рис. 4.1. Документацил SDK c пространством имен и информациеи сборки длл типа 
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Как разнне компонентм взаимодеиствукзт 
во времв ВБтолненив 

В зтом разделе рассказано, как во времн вмполненин взаимодеиствугот типм, обв- 
ектм, стек потока и управлнемал куча. Кроме того, обЂнснено, в чем различие между 
вмзовом статических, зкземплнрнмх и виртуалБнмх методов. А начнем мм с не- 
котормх базовмх сведении о работе комш>готера. То, о чем н собирагосБ рассказатБ, 
вообгце говорн, не относитсн к специфике CLR, но н начну с обгцих понлтии, а затем 
переиду к обсуждениго информации, относигцеиси исклгочителвно к CLR. 

На рис. 4.2 представлен один процесс Microsoft Windows с загруженнои в него 
ИСПОЛ 1 Ш loineii средои CLR. У процесса может 6мтб много потоков. После создании 
потоку вмделиетсл стек размером в 1 Мбаит. Вмделеннал памнтБ исполБзуетсн 
длл передачи параметров в методм и храненин определеннмх в пределах методов 
локалБнмх переменнмх. На рис. 4.2 справа показана памнтБ стека одного потока. 
Стеки заполннготсн от области верхнеи памнти к области нижнеи памнти (то естБ от 
старших к младшим адресам). На рисунке поток уже вБшолнлет какои-то код, и в его 
стеке уже еств какие-то даннБ1е (отмеченБ1 областБГО более темного оттенка вверху 
стека). А теперв представим, что поток ввшолннет код, вБИБшагогции метод Ml. 

Стек потока 

f N • 

void М1() { • 

String name = "Јое"; _•_ 

M2(name); 

return; 

Ч_ _ ) 


Рис. 4.2. Стек потока перед вшовом метода М1 

Все методБЕ, кроме самБ1х простБ1х, содержат некоторБпг входноп код (prologue 
code), инициализиругогции метод до начала его работнг. Кроме того, зти методиг со- 
держат виходноп код (epilogue code), вбшолиигогции очистку после того, как метод 
завершит свого основнуго работу, чтобвг возвратитв управление вБгзвшагогцеи про- 
грамме. В начале вБгполненгш метода М1 его входнои код ввтделнет в стеке потока 
памнтБ длл локалБнои переменнои name (рис. 4.3). 

Далее М1 вБгзнгвает метод М2, передаван в качестве аргумента локалвнуго перемен- 
нуго name. При зтом адрес локалБнои переменнои name заталкиваетсн в стек (рис. 4.4). 
Внутри метода М2 местоположение стека хранитсн в переменнои-параметре s. (Кста- 
ти, в некоторвгх процессорнБгх архитектурах длн повБгшенин производителБности 
аргументБг передаготсл через регистрнг, но зто различие дли нашего обсужденил 
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несутцественно.) При вмзове метода адрес возврата в вмзмвакнции метод также 
заталкиваетсл в стек (показано на рис. 4.4). 


Стек потока 


void М1() { 
String name 
M2(name); 

return; 



} JlOKanbHbie переменнне 
метода М1 


Рис. 4.3. Размеидение локалинои переменнои метода М1 в стеке потока 


Стек потока 


void М1() { 
String name = 

М2( name) ; 

return; 


void M2(String s) { 

Int32 length = s.Length; 
Int32 tally; 


return; 


name (String) 


s (String) 


[адрес возврата] 


IflOKanbHbie nepeMeHHbie метода М1 
) PiapaMeTpbi метода M2 


Рис. 4.4. При вмзове М2 метод М1 заталкивает аргументм 
и адрес возврата в стек потока 


В начале вмполненин метода М2 его входнои код вмделиет в стеке потока памитт. 
дли локалБнмхпеременнмх length и tally (рис. 4.5). Затем вмполннетсн код метода 
М2. В конце концов, вмполнение М2 доходит до командм возврата, которан запи- 
смвает в указателБ команд процессора адрес возврата из стека, и стековБш кадр М2 
возврагцаетси в состонние, показанное на рис. 4.3. С зтого момента продолжаетси 
вБшолнение кода Ml, которБП! следует сразу за вбиовом М2, а стсковбш кадр метода 
находитси в состоинии, необходимом длн работБ 1 Ml. 

В конечном счете, метод М1 возврагцает управление вБШБшакнцеи программе, 
устанавливаи указателБ команд процессора на адрес возврата (на рисунках не по- 
казан, но в стеке он находитсл примо над аргументом name), и стековиш кадр М1 
возврагцаетси в состонние, показанное на рис. 4.2. С зтого момента продолжаетси 
вБгаолнение кода вБМвавшего метода, причем начинает вбшолннтбсн код, непосред- 
ственно следукнции за вбиовом Ml, а стековБш кадр вБ13вавшего метода находитси 
в состоинии, необходимом дли его работБг 
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> JlcmanbHbie переменнне метода М1 
1 flapaMeTpbi метода М2 


Ј JloKaobHbie nepeMeHHbie метода М2 


Рис. 4.5. Вмделение в стеке потока памлти дпл локалвнмх переменнв 1 х метода М2 

А сеичас даваите переклкзчимсн на hciio.tiimioihvio среду CLR. Допустим, естБ 
следукшдие два определенин классов: 

internal class Employee { 

public Int32 GetYearsEmployed () { ... } 

public virtual String GetProgressReport () { ... } 

public static Employee Lookup(String name) { ... } 

} 

internal sealed class Manager : Employee { 

public override String GenProgressReport() { ... } 

} 

Процесс Windows запустилси, в него загружена среда CLR, инициализирована 
управлнемаи куча, и создан поток (с его 1 Мбаит памнти в стеке). Поток уже вбшол- 
ннет какои-то код, из которого вБгзБшаетси метод МЗ (рис. 4.6). Метод МЗ содержит 
код, продемонстриругогции, как работает CLR; врнд ли Bbi будете вклгочатБ такои 
код в свои приложенгш, потому что он, в сугцности, не делает ничего полезного. 

В процессе преобразовангш IL -кода метода МЗ в машиннвге командБг Ј 1 Т-ком- 
пилнтор вБшвлнет все типбг, на которнге естБ ссбшки в МЗ, — зто типбг Employee, 
Int32, Managen и Stning (из-за наличгш строки "Зое"). На данном зтапе CLRo6e- 
спечивает загрузку в домен приложении всех сборок, в которвгх определенБг все зти 
типбг. Затем, исполБзун метаданнБге сборки, CLR получает информациго о типах 
и создает структуркг данннгх, собственно и представлигогцие зти типбг. СтруктурБг 
даннБгх длл обБектов-типов Employee и Managen показанвг на рис. 4 . 7 . Посколнку 
до вБгзова МЗ поток уже вбшолнил какои-то код, дли простоткг допустим, что о6б- 
ектБг-типБг Int32 и Stning уже созданБг (что вполне возможно, так как зто часто 
исполБзуемБге типбг), поотому они не показанБг на рисунке. 

На минуту отвлечемси на обсуждение обБектов-типов. Как говорилосв ранее 
в зтои главе, все обвектБг в куче содержат два дополнителвнБгх члена: указа- 
телБ на обвект-тип и индекс блока синхронизацгш. В обвектах типа Employee 
и Managen оба зти члена присутствугот. При определении типа можно вклгочитб 


void М1() { 

String name = "Јое"; 
M2(name); 


return; 


void M2(String s) { 

Int32 length = s.Length; 
Int32 tally; 


return; 


Стек потока 


name (String) 


s (String) 


[адрес возврата] 


length (I nt32) 


tally (I nt32) 
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в него статические полн даннмх. Баитм длл отих статических полеи вмделиготси 
в составе самих обЂектов-типов. Наконец, у каждого обвекта-типа естЂ таблица 
методов с входнмми точками всех методов, определеннмх в типе. Зта таблица ме- 
тодов уже обсуждаласЂ в главе 1. Так как в типе Employee определенм три метода 
(GetYeansEmployed, GenProgressReport и Lookup), в соответствугошеи таблице 
методов естЂтри записи. В типе Manager определен один метод (переопределеннми 
метод GenProgressReport), которми и представлен в таблице методов зтого типа. 


Стек потока 



Рис. 4.6. Среда CLR загружена в процесс, куча инициализирована, готовитсл визов 
стека потока, в которми загружен метод МЗ 


Стек потока 

- Куча 

: r 


void М3() { 

Employee е; 

Int32 уеаг; 

е = new ManagerO; 

е = Employee.LookupC'Joe"); 

уеаг = e.GetYearsEmployed(); 

e.GetProgressReport(); 


J ч. 


ОбБект-тип Manager 

Указателе на обнект-тип 
Индекс блока синхронизации 
Статические пола 
GetProgressReport 


Обт,ект-тип Employee 

Указателц на обкект-тип 
Индекс блока синхронизации 
Статические пола 
GetYearsEmpIoye'd 
GetProgressReport 
Lookup 


Ј 


Рис. 4.7. При внзове МЗ создакзтсл oGteKTbi типа Employee и Manager 
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После того как среда CLR создаст все необходимме дли метода обЂектм-типм 
и откомпилирует код метода МЗ, она приступает к вмполненшо машинного кода 
МЗ. При вмполнении входного кода МЗ в стеке потока вмделнетси памнтБ длл ло- 
калБнмх переменнмх (рис. 4.8). В частности, CLR автоматически инициализирует 
все локалБнме переменнме значением null или 0 (нулем) — зто делаетсл в рамках 
вмполненгш входного кода метода. Однако при попмтке обрагцентш к локалБнои 
переменнои, ненвно инициализированнои в вашем коде, компилитор C# вБвдаст 
сообшение об ошибке Use of unassigned local variable( испо.т 1 )ЗОнапие пеипи- 
циализированнои локалБнои переменнои). 


Рис. 4.8. Вмделение памлти в стеке потока дпл локалвнв 1 х переменнв 1 х метода МЗ 

Далее МЗ вмполниет код создангш обвекта Manager. При зтом в управлнемои 
куче создаетсн зкземплнр типа Managen, то естБ обБект Managen (рис. 4.9). У обкекта 
Managen — так же как и у всех осталвнБгх обЂектов — еств указателБ на обЂект-тип 
и индекс блока синхронизации. У зтого обБекта тоже естБ баитБ 1 , необходимБге 
длл размегценин всех зкземплнрнБгх полеи даннБгх, определеннБге в типе Managen, 
а также всех зкземплнрнБгх полеи, определеннБгх во всех базоввгх классах типа 
Managen (в данном случае — Employee и Object). Всикии раз при создании ново- 
го обЂекта в куче CLR автоматически инициализирует внутреннии указателв на 
обЂект-тип так, что6бг он указншал на соответствукшџш обЂект-тип (в данном 
случае — на обЂект-тип Managen). Кроме того, CLR инициализирует индекс блока 
синхронизации и присваивает всем зкземплнрнБш полим обБекта значение null 
или 0 (нулк) перед вбгзовом конструктора типа — метода, которвш, скорее всего, 
изменит значенгш некоторвгх зкземплнрнвгх полеи. Оператор new возврагцает адрес 
в памити обвекта Managen, которвш хранитсн в переменнои е (в стеке потока). 


Куча 


Обг>ект-тип Manager 


Указателћ на обеект-тнп 
Индекс блока синхронизации 
Статические полл 
GetProgressReport 


Обт>ект-тип Employee 


Указателе на об 1 ект-тип 
Индекс блока синхронизации 
Статические полл 
GetYearsEmployed 
GetProgressReport 
Lookup 


Стек потока 



• null 


void М3() { 

Employee е; 

Int32 уеаг; 
е = new ManagerO; 
е = Employee.Lookup("Joe"); 
уеаг = e.GetYearsEmployed(); 
e. GetProgressReportO; 


v_ 
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Стек потока 



Рис. 4.9. Создание и инициализациа обБекта Manager 

Следуготцаи строка метода МЗ вмзмвает статическии метод Lookup обЂекта 
Employee. При вмзове зтого метода CLR определнет местонахождение обЂекта-типа, 
соответствугогцего типу, в котором определен статическии метод. Затем на основании 
таблицм методов обЂекта-типа среда CLR находит точку входа в вмзмваемми метод, 
обрабатмвает код JIT -компилитором (при необходимости) и передает управление 
полученному машинному коду. Длн нашего обсужденин достаточно предположитЂ, 
что метод Lookup обЂекта Employee вмполннет запрос к базе даннмх, чтобм наити 
сведенин о Doe. Допустим также, что в базе даннмх указано, что loe занимает долж- 
ностђ менеджера, позтому код метода Lookup создает в куче новми обЂект Managen, 
инициализирует его даннмми Doe и возврагцает адрес готового обЂекта. Адрес раз- 
мегцаетси в локалвнои переменнои е. Резулнтат зтои операции показан на рис. 4.10. 

Следугогцаи строка метода МЗ вмзмвает виртуалвнми зкземплнрнми метод 
GenPnognessRepont в Employee. При вмзове виртуалвного зкземплнрного метода 
CLR приходитсл вмполнитђ некоторуго дополнителЂнуго работу. Во-первмх, CLR 
обрагцаетсн к переменнои, исполвзуемои длн вмзова, и затем следует по адресу вм- 
змвагогцего обЂекта. В данном случае переменнан е указмвает на обнект Doe типа 
Managen. Во-втормх, CLR провернет у обкекта внутреннии указателв на обЂект-тип. 
Затем CLR находит в таблице методов обЂекта-типа записн вмзмваемого метода, 
обрабатмвает код JIT -компшштором (при необходимости) и вмзмвает полученнми 
машиннми код. В нашем случае вмзмваетси реализацгшметода GenPnognessRepont 
в Managen, потому что е ссмлаетсн на обнект Managen. Резулвтат зтои операции 
показан на рис. 4.12. 

Заметше, если метод Lookup в Employee обнаружит, что Doe — зто всего лишђ 
Employee, а не Managen, то Lookup создаст обнект Employee, в котором указателв на 
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обЂект-тип ссмлаетсн на обЂект-тип Employee; зто приведет к тому, что вмполнитсн 
реализацин GenProgressReport из Employee, а не из Manager. 


Стек потока 



Рис. 4.10. Статическии метод Lookup в Employee вмделпет памлтв 
и инициализирует обвект Manager длп Јое 


Стек потока 



Рис. 4.11 . Невиртуалвнми зкземпллрнни метод GetYarsEmployeed в Employee 

возвраидает значение 5 


Итак, мм обсудили взаимоотношении между исходнмм текстом, IL и машиннмм 
JIT -кодом, поговорили о стеке потока, аргументах и локалвнмх переменнмх, а также 
о том, как ::)■[■ и аргументм и переменнме ссмлаготсн на обЂектм в управлнемои куче. 
Мм также узнали, что обЂектм храннт указателк на свои обЂект-тип (содержагции 
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статические полн и таблицу методов). Мм обсудили, как CLR вмзмвает статические 
методм, невиртуалБнне и виртуалБнме зкземплнрнме методм. Все сказанное при- 
звано датБ вам более полнукз картину работБ 1 CLR и помочб при создании архитек- 
турБ 1 , проектировании и реализации типов, компонентов и приложении. Заканчиван 
главу, м хотел 6bi сказатв егце несколБКО слов о происходнгцем внутри CLR. 


Стек потока 



Рис. 4.12. При Bbi3oee виртуалвного метода GenProgressReport зкземплчра Employee 
будет Bbi3BaHa переопределеннач реализацил зтого метода в Manager 


Стек потока 



Рис. 4.13. Обвекти типа Manager и Employee как зкземплчрв! типа System.Type 

Наверннка bbi обратите внимание, что о6ђсктб1 типа Employee и Manager содер- 
жат указатели на обБектБ1-типБ1. По сути обБектБ1-типБ1 тоже нвлнкзтсн обБектами. 
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Создаван обЂект-тип, среда CLR должна его как-то инициализироватБ. Резонно 
спроситћ: «Какие значенгш будут присвоенБг при инициализации?» В обгцем, при 
своем запуске в процессе CLR сразу же создает слециалБНБш обЂект-тип длн типа 
System.Type (он определенв MSCorLib.dll). ОбБектвгтипа Employee и Managen нвлн- 
io'i c'm «зкземплнрами» зтого типа, и по зтои причине их указатели на о6б6Ктб1-типб1 
инициализируготсл ссбшкои на обнект-тип System. Туре (рис. 4.13). 

Конечно, обнект-тип System . Туре сам ивлнетсч обвектом и позтому также со- 
держит указателв на обЂект-тип; значит, закономерно поинтересоватБСл, на что 
ссБшаетсн зтот указателБ. А ссБшаетсн он на самого себн, так как обБект-тип Sy stem . 
Туре сам по себе нвлнетсл «зкземплиром» обЂекта-типа. ТеперБ становитсл поннт- 
но, как устроена и работает всн система типов в CLR. Кстати, метод GetType типа 
System.Object просто возврагцает адрес, храннгциисл в указателе на обЂект-тип 
заданного обнекта. Иначе говори, метод GetType возврагцает указателв на обнект- 
тип указанного обнекта и именно позтому можно определитБ истиннбш тип лгобого 
обЂекта в системе (вклгочап обЂектБг-типБг). 



Глава 5 . Примитивн1>1е, ccbmonHbie 
и значимме типн 


В зтои главе речБ идет о разновидностлх типов, с котормми вм будете иметБ дело 
при программировании длн платформБ 1 Microsoft .NET Framework. Важно, что6б1 
все разработчики четко осознавали разницу в поведении типов. Приступан к изуче- 
1 шк) .NET Framework, и толком не понимал, в чем разница между примитивнБши, 
ССБ1ЛОЧНБШИ и значимБши типами, в резулвтате мои код получалсн не слишком 
зффективнБш и содержал много коварнБ1х ошибок. Е[адек>СБ, .vioii опб1т и мои о6ђ- 
нсненин различии между зтими типами помогут вам избавитвсн от лишних проблем 
и повБШитБ производителБностБ своеи работвт 


npHMHTHBHbie ТИПБ1 

в лзмках программированил 

Е1екоторБ1е типб 1 даннБ 1 х примегодатси так часто, что дли работБ 1 с ними во многих 
компилнторах предусмотрен упрогценнБпт синтаксис. Е1апример, целуго переменнуго 
можно создатБ следугогцим образом: 

System.Int32 а = new System.Int32(); 

Конечно, подобнБ 1 и синтаксис длн обБлвленин и инициализации целои перемен- 
Hoii кажетсл громоздким. К счаствго, многие компилиторБ 1 (вклгочан С#) позволнгот 
исполвзоватБ вместо зтого более проствге вБфажении, например: 

int а = 0; 

11одобш>ш код читаетси намного лучше, да и компиллтор в обоих случаих гене- 
рирует идентичнБ 1 и IL -код длн System . Int32. Типб 1 даннБ 1 х, которБШ поддержива- 
готси компилнтором напримуго, назвшаготсн примитивними (primitive types); у них 
сушествугот примБге аналоги в библиотеке классов .NET Framework Class Library 
(FCL). Е1апример, типу int нзвпса C# соответствует System. Int32, позтому весв сле- 
дугогции код компилируетсл без ошибок и преобразуетсн в одинаковвге IL -командБК 

int а = 0; // CaMbiPi удобнми синтаксис 

System.Int32 а = 0; // Удобнми синтаксис 
int а = new int(); // Неудобнми синтаксис 

System.Int32 а = new System.Int32( ); // Самти неудобнни синтаксис 
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В табл. 5.1 представленм типм FCL и соответствуготцие им примитивнме типм 
С#. В других лзмках типам, удовлетворигогцим обгцензмковои спецификацгш 
(Common Language Specification, CLS), соответствугот аналогичнме примитивнме 
типм. Однако поддержка нзмком типов, не удовлетворнгогцих требовангшм CLS, 
не обнзателБна. 


Таблица 5.1. ПримитивнБ 1 е типн C# и соответствугоидие типн FCL 


Прими- 

THBHbl и 

тип 

FCL -тип 

Совме- 

CTHMOCTb 

cCLS 

Описание 

sbyte 

System.Sbyte 

Нет 

8-разрндное значение со знаком 

byte 

System.Byte 

Да 

8-разрндное значение без знака 

short 

System.Intl6 

Да 

16-разрндное значение со знаком 

ushort 

System.Uintl6 

Нет 

16-разрндное значение без знака 

int 

System.Int32 

Да 

32-разрндное значение со знаком 

uint 

System.Uint32 

Нет 

32-разрндное значение без знака 

long 

System.Int64 

Да 

64-разрндное значение со знаком 

ulong 

System.Uint64 

Нет 

64-разрндное значение без знака 

char 

System.Char 

Да 

16-разрнднни символ Unicode (char ни- 
когда не представллет 8-разрндное значе- 
ние, как в неуправллемом коде на С++) 

float 

System.Single 

Да 

32-разрндное значение с плаваготеи точ- 
кои в стандарте IEEE 

double 

System.Double 

Да 

64-разрндное значение с плавагопгеи точ- 
кои в стандарте IEEE 

bool 

System.Boolean 

Да 

Булево значение (true или false) 

decimal 

System.Decimal 

Да 

128-разрндное значение с плавагогцеи 
точкои повБгшеннои точности, часто 
исполвзуемое длл финансоввгх рас- 
четов, где недопустимБ! ошибки округ- 
ленгш. Один разрчд числа — зто знак, 
в следугогцих 96 разрлдах помепгаетсл 
само значение, следукнцие 8 разрчдов — 
степенБ числа 10, на которое делитсл 
96-разрндное число (может 6бгтб в диа- 
пазоне от 0 до 28). ОсталвнБге разрндБг 
не исполБзуготсл 


продолжение # 
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Таблица5.1 ( продолжение) 


Прими- 

TMBHbl и 

тип 

FCL -тип 

Совме- 

CTMMOCTb 

cCLS 

Описание 

string 

System.String 

Да 

Массив символов 

object 

System.Object 

Да 

Базоввги тип длл всех типов 

dynamic 

System.Object 

Да 

Длл CLR тип dynamic идентичен типу 
object. Однако компиллтор C# позволлет 
переменнБШ типа dynamic участвоватБ 
в динамическом разрешении типа с упро- 
гценнБгм синтаксисом. Подробнее об 
зтом читаите в разделе «ПримитивнБ 1 и 
тип даннБхх dynamic» в конце зтои главБ! 


Иначе говори, можно считатБ, что компилитор C# автоматически предполагает, 
что во всех фаилах исходного кода естБ следугогцие директивБ1 using (как говори- 
лосб в главе 4): 

using sbyte = System.SByte; 
using byte = System.Byte; 
using short = System.Intl6; 
using ushort = System.UIntl6; 
using int = System.Int32; 
using uint = System.UInt32; 

И не могу согласитБСн со следугогцим утверждением из спецификации изшса 
С#: <<С точки зренгш стилл программировангш предпочтителвнеи исполБЗОватБ 
клгочевое слово, а не полное системное имн типа», позтому старагосв задеиствоватБ 
имена FCL -тгшов и избегатв имен примитивнБгх типов. Па самом деле, мне 6 бг хоте- 
лосб, что6б1 имен примитивнБгх типов не бвшо совсем, а разработчики употреблнли 
толбко имена FCL -тгшов. И вот по каким причинам. 

□ Мне попадалисв разработчики, не знавшие, какое клгочевое слово иснолбзо- 
ватБ им в коде: string или String. В C# зто не важно, так как клгочевое слово 
string в точности преобразуетсл в FCL -тип System.String. И также слвшгал, 
что некоторБге разработчики говорили о том, что в 32-разрндш>1х операционнвгх 
системах тип int представлилси 32-разриднвш типом, а в 64-разрнднв1х — 64- 
разриднБш типом. Зто утверждение совершенно неверно: в C# тип int всегда 
преобразуетсл в System . Int32, позтому он всегда представлнетсн 32-разрнднвш 
типом безотносителвно запугценнои операционнои системБк ИсполБЗОвание 
клгочевого слова Int32 в своем коде позволит избежатв путаницБк 

□ В C# long соответствует тип System . Int64, но в другом извпсе зто может 6бгтб 
Intl6 или Int32. Как известно, в C++/CLI тип long трактуетсн как Int32. Если 
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кто-то возБметсл читатБ код, написаннни на новом длн себн нзмке, то назначение 
кода может бљт> неверно им истолковано. Многим нзмкам незнакомо клгочевое 
слово long, и их компилиторм не пропустлт код, где оно встречаетсч. 

□ У многих FCL -типов ес гр> методм, в имена котормх вклгоченм имена типов. Fla- 
пример, у типа BinaryReader естБ методм ReadBoolean, Readlnt32, ReadSingle 
и т. д., а у типа System.Convert — методм ToBoolean, ToInt32, ToSingle и т. д. 
Вот вполне приемлемми код, в котором строка, содержагцан f loat, вмглндит 
неестественно; даже возникает впечатление, что код ошибочен: 

BinaryReader br = new BinaryReader( ...); 

float val = br.ReadSingle(); // Код правилвнии, но вв 1 гллдит странно 
Single val = br . ReadSingle( ); // Код правилинии и вигллдит нормалвно 

□ Многие программистм, пишугцие исклгочителБно на С#, часто забБгвагот, что 
в CLR могут применнтБСн и другие нзбгки программированин. В1апример, среда 
FCL практически полностбго написана на С#, а разработчики из командкг FCL 
ввели в библиотеку такие методвг, как метод GetLongLength класса Аггау, воз- 
врагцагогции значение Int64, которое имеет тггп long в С#, но не в других нзвгках 
программировангш (например, C++/CLI). Другои пример — метод LongCount 
класса System . Linq . Enumerable. 

По зтим причинам н буду исполвзоватв в зтои книге толбко имена FCL -типов. 
Во многих извгках программированин следугогции код благополучно скомпи- 
лируетсл и вбгполнитсл: 

Int32 i = 5; // 32-раврлдное число 

Int64 1 = i; // Нелвное приведение типа к 64-разрлдному значенит 

Однако если вспомнитб, что говорилосБ о приведении типов в главе 4, можно 
решитв, что он компилироватБСи не будет. Все-таки System . Int32 и System. Int64, 
не нвлиготсн производнвгми друг от друга. Могу вас обнадежитв: код успешно ком- 
пилируетсн и делает все, что ему положено. Дело в том, что компилнтор C# неплохо 
разбираетсн в примитивнБгх типах и применнет свои правила при компилнции кода. 
Иначе говорн, он распознает наиболее распространеннвге шаблонвг программиро- 
ванин и генерирует такие IL -командвг, благодари которвгм исходнбги код работает 
так, как требуетсл. В первуго очередв, зто относитсн к приведениго типов, литералам 
и операторам, примервг которвгх мбг рассмотрим позже. 

Начнем с того, что компилитор вБгполннет нвное и нечвное приведение между 
примитивнБгми типами, например: 


Int32 i = 5; 

// 

Нелвное приведение 

Int32 

к 

Int32 

Int64 1 = i; 

// 

Нелвное приведение 

Int32 

к 

Int64 

Single s = i; 

// 

Нелвное приведение 

Int32 

к 

Single 

Byte b = (Byte) i; 

// 

Нвное приведение Int32 к 

Byte 


Intl6 v = (Intl6) s; // Лвное приведение Single к Intl6 


C# разрешает ненвное приведение типа, если зто преобразование «безопасно», 
то еств не сопрнжено с потереи данннгх; пример — преобразование из Int32 в Int64. 
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Однако длн преобразованнн с риском потери даннмх C# требует нвного приведенин 
типа. Длн числовмх типов «небезопасное» преобразование означает <<свнзанное с по- 
тереи точности или величинм числа». Например, преобразование из Int32 в Byte 
требует лвного приведенил к типу, так как при бо.ттпих величинах Int32 терлетси 
точностб; требует приведенин и преобразование из Single в Intl6, посколБку число 
Single может оказатмш болБше, чем допустимо длн Intl6. 

Длн реализации приведенил разнвш компилиторм могут порождатБ разнми 
код. Например, в случае приведенгш числа 6,8 типа Single к типу Int32 одни ком- 
пшшторм сгенериругот код, которми поместит в Int32 число 6, а другие округлит 
резулБтат до 7. Между прочим, в C# дробнан частБ всегда отбрасвшаетси. Точнбго 
правила приведенгш длл примитивнвш типов bbi наидете в разделе спецификации 
нзв 1 ка С#, посвнгценном преобразовангшм (<<Conversions»). 

Помимо приведенгш, компилитор <<знает» и о другои особенности примитив- 
нб 1 х типов: к ним применима литералвнаи форма записи. ЛитералБ 1 сами по себе 
считаготсл зкземплнрами типа, позтому можно вБИБшатБ зкземплнрнБШ методБц 
например, следуклцим образом: 

Console.WriteLine(123.ToString() + 456.ToString( )); // "123456" 

Кроме того, благодарн тому, что вБфаженгш, состоигцие из литералов, вбиисли- 
готси на зтапе компилнции, возрастает скороств вБшолнешш приложенгш. 

Boolean found = false; // В готовом коде found присваиваетсл 0 

Int32 х = 100 + 20 + 3; // В готовом коде х присваиваетсв 123 

Stning s = "а " + "bc"; // В готовом коде s присваиваетсв "а bc" 

И наконец, компилнтор «знает», как и в каком порндке интерпретироватв 

встретившиесл в коде операторв 1 (в том числе +, -, *, /, %, &, л , |, ==, ! =, >, <, >=, <=, 
<<, >>, ~, !,++,-- ит.п.): 

Int32 х = 100; // Оператор присваиванив 

Int32 у = х + 23; // Операторм суммированив и присваивании 

Boolean lessThanFifty = (у < 50); // Операторм "менвше чем" и присваиванив 


Проверлемме и непровервемме операции 
длв примитивнмх типов 

Программистам должно 6bitb хорошо известно, что многие арифметические опе- 
рации над примитивнвши типами могут привести к переполнениго: 

Byte b = 100; 

b = (Byte) (b + 2 00);// После зтого b равно 44 (2C в шестнадцатеричнои записи) 

Такое «незаметное» переполнение обвшно в программировании не приветству- 
етси, и если его не вбшвитб, приложение поведет себн непредсказуемо. Изредка, 
правда (например, при вБшислении хеш-кодов или контролБНБ1х сумм), такое 
переполнение не толбко приемлемо, но и желателнно. 
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ВНИМАНИЕ 

При ввтолнении зтои арифметическои операции CLR на первом шаге все значенил 
операндов расширлизтсп до 32 разрлдов (или 64 разрлдов, если длл представленил 
операнда 32 разрлдов недостаточно). Позтому b и 200 (длл которих 32 разрлдов 
достаточно) сначала преобразукзтсл в 32-разрлднме значенил, а затем уже сумми- 
рукзтсл. Полученное 32-разрлдное число (300 в деслтичнои системе, 12С в шестна- 
дцатеричнои), прежде чем поместитБ его обратно в переменнукз b, нужно привести 
к типу Byte. Так как в данном случае C# не вмполнлет нелвного приведенил типа, во 
вторукз строку введена операцил приведенил ктипу Byte. 


В каждом измке сушествугот свои способм обработки переполнешш. В С и С++ 
переполнение ошибкои не считаетсн, а при усечении значении приложение не пре- 
рвет cboio работу. А вот в Visual Basic переполнение всегда рассматриваетсл как 
ошибка, и при его обнаружении генерируетси исклгочение. 

В CLR естБ IL -командм, позволнгогцие компилитору по-разному реагироватБ 
на переполнение. Например, суммирование двух чисел вмполннет команда add, не 
реагиругогцан на переполнение, а также команда add . ovf , котораи при переполне- 
нии генерирует исклгочение System.OvenflowException. Кроме того, в CLR естБ 
аналогичнБге IL -командБг длн ВБГчитанил (sub/sub . ovf ), умноженин (mul/mul . ovf ) 
и преобразованин даннБгх (conv/conv . ovf ). 

Пишугции на C# программист может сам решатБ, как обрабатБшатБ переполне- 
ние; по умолчаниго проверка переполненгш отклгочена. Зто значит, что компшштор 
генерирует длн операции сложенин, вБгчитании, умноженип и преобразовашш IL- 
командБг без проверки переполненгш. В резулБтате код вБгполннетсн бигстро, но раз- 
работчггк должен 6бгтб либо уверен в отсутствии переполненгш, либо предусмотретБ 
возможностб его возникновенгш в своем коде. 

Что6бг вклгочитб механизм управлении процессом обработки переполне- 
шш на зтапе компилнции, добавБте в команднуго строку компилнтора параметр 
/checked+. Он сообгцает компшштору, что длл вБгполненгш сложенгш, вБшитангш, 
умноженггн и преобразованин должнбг 6бгтб сгенерированБг IL -командБг с проверкои 
переполнешш. Такои код медленнее, так как CLR тратит времн на проверку зтих 
операции, ожидан переполнение. Когда оно возникает, CLR генерирует исклгоче- 
ние Ovenf lowException. Код приложенгш должен предусматриватБ корректнуго 
обработку зтого исклгоченип. 

Однако программистам врнд ли понравитсл необходимостБ вклгоченин или от- 
клгочешш режима проверки переполненин во всем коде. Им лучше самим решатБ, как 
реагироватБ на переполнение в каждом конкретном случае. И C# предлагает такои 
механизм гибкого управленгш проверкои в виде операторов checked гг unchecked. На- 
пример (предполагаетси, что компилнтор по умолчаниго создает код без проверки): 
UInt32 invalid = unchecked((UInt32) -1); // 0К 

А вот пример с исполБЗОванием оператора checked: 

Byte b = 100; // Ввдаетсн исклтчение 

b = checked((Byte) (b + 200)); // OverflowException 
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Здесћ b и 200 преобразуготсл в 32-разриднме числа и суммируготсл; резулБ- 
тат равен 300. Затем при преобразовании 300 в Byte генерируетси исклгочение 
OvenflowException. Если приведение к типу Byte вмвести из оператора checked, 
исклгоченгш не будет: 

b = (Byte) checked(b + 200); // b содержит 44; нет OverflowException 

Нариду c операторами checked и unchecked в C# еста одноименнмеинструк- 
ции, позволнгогцие вклгочитб провериемме или непровернемме вмраженгш внутрБ 
блока: 

checked { // Начало проверлемого блока 

Byte b = 100; 

b = (Byte) (b + 200); // Зто внражение проверлетсв на переполнение 
} // Конец проверлемого блока 

Кстати, внутри такого блока можно задеиствоватБ оператор += с Byte, которми 
немного упростит код: 

checked { // Начало проверлемого блока 

Byte b = 100; 

b += 200; // Зто вмражение проверлетсв на переполнение 

} // Конец проверпемого блока 


ВНИМАНИЕ 

Установка режима контролл переполненил не влилет на работу метода, вц13мваемого 
внутри оператора или инструкции checked, так как деиствие оператора (и инструк- 
ции) checked распространлетсл толцко на вмбор IL -команд сложенил, вц|читанил, 
умноженил и преобразованил даннц|х. Например: 

checked { 

// Предположим, SomeMethod пнтаетсл поместити 400 в Byte 
SomeMethod(400); 

// Возникновение OverflowException в SomeMethod 
// зависит от наличил в нем операторов проверки 

} 

И видел немало вмчислении, генериругогцих непредсказуемме резулкгатм. 
Обмчно зто случаетсл из-за неправилБного ввода даннмх полБЗОвателем или же 
из-за возврагценгш неожиданнмх значенгш переменнмх. Итак, и рекомендуго про- 
граммистам соблгодатБ следугогцие правила при исполБЗОвании операторов checked 
и unchecked. 

□ Исполћзуите типм со знаком (Int32 и Int64) вместо числовмх типов без знака 
(UInt32 и UInt64) везде, где зто возможно. Зто позволит компилитору вбшв- 
ллтб ошибку переполненгш. Кроме того, некоторБге компонентБг библиотеки 
классов (например, своиства Length классов Аггау и Stning) жестко запро- 
граммированБг на возврагцение значении со знаком, и передача зтих значении 
в коде потребует менБшего количества преобразовании типа (а следователБно, 


Примитивнме Tnnbi в H3biKax программированин 149 

упростит структуру кода и его сопровождение). Кроме того, числовме типм без 
знака несовместимм с CLS. 

□ Вклгочаите в блок checked ту частБ кода, в которои возможно переполнение из- 
за невернБгх входнбгх ддннбгх, например при обработке запросов, содержагцих 
даннвге, предоставленнБге конечнБш полБЗОвателем или клиентскои машинои. 
Возможно, также стоит перехватвшатв исклгочение OverflowException, что6бг 
ваше приложение могло корректно продолжитв работу после таких сбоев. 

□ Вклгочаите в блок unchecked те фрагментвг кода, в которвгх переполнение не 
создает проблем (например, при вбгчислспии контролБнои cy.vi.vibi). 

□ В коде, где нет операторов и блоков checked и unchecked, предполагаетсл, что 
при переполнении должно происходитв исклгочение. Например, при вБиислении 
простБгх чисел входнбш даннБге известнБ1, а переполнение нвлиетсл признаком 
ошибки. 

В процессе отладки кода установите параметр компилнтора /checked+. Ввшолне- 
ние приложенин замедлитсн, так как система будет контролироватв переполнение во 
всем коде, не помеченном клгочеввши словами checked или unchecked. Обнаружив 
исклгочение, bbi сможете легко обнаружитв его и исправитБ ошибку. В окончателБнои 
сборке приложенгга установите параметр /checked-, что ускорит ввшолнение при- 
ложенгга; исклгоченгга при зтом генерироватБСи не будут. Дли того что 6 б 1 изменитБ 
значениепараметра checked в Microsoft Visual Studio, откроитеокно своиств вашего 
проекта, переидите на вкладку Build, гцелкните на кнопке Advanced и установите 
флажок Check for arithmetic overflow/underflow, как зто показано на рис. 5.1. 
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Рис. 5.1. Изменение применземмх по умолчаник) параметров компиллтора 
Visual Studio в окне Advanced Build Settings 


В случае если длн вашего приложенгга производителвностБ не критична, н реко- 
мендуго оставлитБ параметр /checked вклгоченнБш даже в окончателвнои версии. 
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Зто позволит затцититБ приложение от некорректнБ1х даннБ1х и брешеи в системе 
безопасности. Например, если при вмчислснии индекса массива исполвзуетсн 
исклгочение, лучше получитк исклгочение OvenflowException, чем обратитБСн 
к неверному злементу массива из-за переполненин. 

ВНИМАНИЕ 

Тип System.Decimal стоитособнлком. В отличие от многих лзмков программированил 
(вклкзчал C# и Visual Basic), в CLR тип Decimal не относитсл к примитивнБ 1 м типам. 
В CLR нет IL -команддлч работн созначениимитипа Decimal. В документации по .NET 
FrameworkcKa3aHO, что тип Decimal имеетоткри™е статические методБ 1 -членБ 1 Add, 
Subtract, Multiply, Divide и прочие, а также перегруженнме операторм +, -, *, / и т. д. 

При компиллции кода с типом Decimal компиллтор генерирует Bbi30Bbi членов 
Decimal, KOTopbie и BbinonHniOT реалину !0 работу. Позтому значенил типа Decimal 
обрабативак>тсл медленнее примитивнв 1 х CLR -типов. Кроме того, раз нет IL -команд 
длл манипулчции числами типа Decimal, то не будут имети зффекта ни операторм 
checked и unchecked, ни соответствукхцие параметрм команднои строки компиллто- 
ра, а неосторожности в операцичхнадтипом Decimal может привести к исклкзчени 10 
OverflowException. 

Аналогично, тип System.Numerics.Biglnteger исполнзуетсл в массивах Ulnt32 длп 
представленил болвшого целочисленного значенил, не имекшдего верхнеи или 
нижнеи границн. Следователвно, операции с типом Biglnteger никогда не вмзовут 
исклкзченил OverflowException. Однако они могут привести к видаче исклкзченил 
OutOfMemoryException, если значение переменнои окажетсл слишком болвшим. 


Ccbmo4Hbie и значимме типн 

CLR поддерживает две разновидности типов: ссилочние (reference types) и значи- 
мие (value types). Болбшинство типов в FCL — ссбшочнбго, но программистБ 1 чагце 
всего исполБзугот значимБге. ПамитБ дли ссбшочнбгх типов всегда вБгделлетсл из 
управлиемои кучи, а оператор C# new возврагцает адрес в памнти, где размегцаетси 
сам обвект. При работе со ссбглочнбгми типами необходимо учитпгватБ следугогцие 
обстонтелБСтва, относигциесц к производителвности приложении: 

□ памитБ длл ссбглочнбгх типов всегда вБгделлетсл из управлнемои кучи; 

□ каждБги обвект, размегцаемБги в куче, содержит дополиителБНБге членБг, под- 
лежагцие инициализации; 

□ незаннтБге полезнои информациеи баитпг обвекта обпули iotc+i (зто касаетси 
полеи); 

□ размегцение обвекта в управлиемои куче со временем инициирует сборку му- 
сора. 

Если 6бг все типбг 6бгли ссбглочнбгми, зффективностБ приложенин резко упала 
6бг. ПредставБте, насколБКО замедлилоск 6бг вБгполнение приложенин, если 6бг при 
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каждом обрашении к значеншо типа Int32 вмделиласБ памлтБ! Позтому, чтобм уско- 
ритБ обработку простмх, часто исполћзуеммх типов CLR предлагает «облегченнме» 
типм — значимие. Зкземплирм зтих типов обмчно размегцакзтси в стеке потока 
(хотн они могут 6мтб встроенм и в oO'bCKT ссмлочного типа). В представлнкпцеи 
зкземплнр переменнои нет указателн на зкземплнр; полн зкземплнра размегцаготси 
в самои переменнои. ПосколБку переменнаи содержит полн зкземплнра, то длн ра- 
ботн с зкземплиром не нужно вмполннтб размменование (dereference) зкземплнра. 
Благодари тому, что зкземплирм значиммх типов не обрабатмваготси уборгциком 
мусора, v.vieiibinacTCTi интенсивностБ работм с управлиемои кучеи и сокрагцаетсн 
количество сеансов уборки мусора, необходиммх приложениго на протлжении его 
сугцествовангш. 

В документации на .NET Framework можно сразу увидетћ, какие типм отно- 
снт к ссмлочнмм, а какие — к значиммм. Если тип назмвагот классом (class), речБ 
идет о ссбшочном типе. Например, классБг System .Object, System. Exception, 
System. 10.FileStream и System.Random — зто ссбшочнбш типбг B свого очередБ, 
значимБге типбг в документацгш назБгваготси структурами (structure) и пере- 
численилми (enumeration). Например, структурм System.Int32, System.Boolean, 
System.Decimal, System.TimeSpan и перечисленгш System.DayOfWeek, System. 
10. FileAttnibutes и System.Dnawing. FontStyle ивлчготси значимБши типами. 

Bce структурБг чвлиготси прпмшми потомками абстрактного типа System. 
ValueType, которБги, в свого очередБ, нвлиетси производнвш от типа System. 
Ob ject. По умолчаниго все значимБге типбг должнбг 6бгтб производнБши от System . 
ValueType. Все перечисленгш нвлнготсл производнБши от типа System . Enum, про- 
изводного от System . ValueType. CLR и нзбиси программировангш по-разному 
работагот с перечисленгшми. О перечислимБгх типах см. главу 15. 

При определении собственного значимого типа нелБЗн вБгбратБ произволБНБпг 
базовБпг тип, однако значимБш тип может реализоватБ один или несколБКО вБгбран- 
нб1х вами интерфеисов. Кроме того, в CLR значимБш тип нвлиетси изолированнБш, 
то естБ он не может служитБ базовБш типом длл какого-либо другого ссбшочного 
или значимого типа. Позтому, например, нелБЗи в описангш нового типа указБшатБ 
в качестве базовБгх типбг Boolean, Chan, Int32, Uint64, Single, Double, Decimal и т. д. 

ВНИМАНИЕ 

Многим разработчикам (в частности, тем, кто пишет неуправлпемми код на С/С++) 
деление на ссБшочнме и значимме типм поначалу кажетсп страннмм. В неуправлле- 
мом коде С/С++ Bbi обвпвлиете тип, и уже код решает, куда поместиљ зкземплпр 
типа: в стек потока или в кучу приложенип. В управлпемом коде иначе: разработчик, 
описмваклции тип, укази 1 вает, где должнм размеидатисл зкземпллри 1 данного типа, 
а разработчик, исполвзук)ш,ии тип в своем коде, управлпљ зтим не может. 


В следугогцем коде (и на рис. 5.2) продемонстрировано различие между ссбшоч- 


нбши и значимБши типами: 
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// Ссмлочнми тип (посколику 'class') 
class SomeRef { public Int32 х; } 

// Значимни тип (посколБку ’struct') 
struct SomeVal { public Int32 х; } 

static void ValueTypeDemo() { 

SomeRef rl = new SomeRef(); // Разме|цаетсл в куче 

SomeVal vl = new SomeVal(); // Размешаетсл в стеке 

rl.x = 5; // Размменовмвание указателл 
vl.x = 5; // Изменение в стеке 
Console.WriteLine(rl.x); // Отображаетсв "5" 
Console.WriteLine(vl.x); // Также отображаетсл "5" 

// В левои части рис. 5.2 показан резулвтат 
// внполненил предмдуших строк 

SomeRef r2 = rl; // Копируетсл толико сснлка (указатели) 

SomeVal v 2 = vl; // Помешаем в стек и копируем членн 

rl.x = 8; // Изменлвтсл rl.x и r2.x 
vl.x = 9; // Изменлетсл vl.Xj но не v2.x 
Console.WriteLine(rl.x); // Отображаетсл "8" 
Console.WriteLine(r2.x); // Отображаетсл "8" 
Console.WriteLine(vl.x); // Отображаетсл "9" 
Console.WriteLine(v2.x); // Отображаетсл "5" 

// В правои части рис. 5.2 показан резулитат 
// внполненил ВСЕХ предндутих строк 

} 


Состолние после виполненил 
первои nonoBHHbi метода ValueTypeDemo 

Стек потока Управллемал куча 



Состолние после окончателвного 
ввтолненил метода ValueTypeDemo 

Стек потока Управллемал куча 



Рис. 5.2. Разница между размеидением в памлти значиммх и ccbmo4HbixTnnoB 


В зтом примере тип SomeVal обЂпвлен с клточевмм словом struct, а не более 
распространеннмм клкзчевмм словом class. В C# типм, обЂнвленнме как struct, 
нвлчкттсн значиммми, аобЂнвленнмекак class, — ссмлочнмми. Между поведением 
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ссбшочнмх и значимБ1х типов cvmecTiiviOT cviuccTiseiiiiiiie различин. Позтому так 
важно представлнтБ, к какому семеиству относитсн тот или инои тип — к ссбшочно- 
му или значимому: ведн зто может сушественно повлинтб на то, как bki вБфажаете 
свои намеренич в коде. 

В предввдушем примере естн следуклцаи строка: 

SomeVal vl = new SomeVal(); // Размецаетсл в стеке 

Может показатБСи, что зкземплнр SomeVal будет помевден в управлнемуго кучу. 
Однако посколвку компилнтор C# «знает», что SomeVal нвлнетсн значимвш типом, 
в сгенерированном им коде зкземплнр SomeVal будет помевден в стек потока. C# 
также обеспечивает обнуление всех полеи зкземплира значимого типа. 

Ту же строку можно записатв иначе: 

SomeVal vl; // Размешаетсп в стеке 

ЗдесБ тоже создаетсл IL -код, которБш помевдает зкземплнр SomeVal в стек по- 
тока и обнулнет все его полн. Единственное отличие в том, что зкземплнр, создан- 
HBiii оператором new, C# «считает» инициализированнБш. Понснго зту мбвдлб на 
следуговдем примере: 

// Две следуклцие строки компилируштсл, так как C# считает, 

// что полл в vl инициализирук)тсл нулем 
SomeVal vl = new SomeVal(); 

Int32 a = vl.x; 

// Следуклцие строки визовут ошибку компилвции, посколцку C# не считает, 

// что полл в vl инициализирук)тсд нулем 
SomeVal vl; 

Int32 а = vl.x; 

// error CS0170: Use of possibly unassigned field 'х' 

// (ошибка CS0170: Исполцзуетсп поле 'х', которому не присвоено значение) 

Проектирул CBoii тип, провервте, не исполвзоватБ ли вместо ссбшочного типа 
значимБш. Иногда зто позволнет повбгситб зффективностБ кода. Сказанное особенно 
справедливо дли типа, удовлетворнговдего всем перечисленнвш далее условинм. 

□ Тип ведет себн подобно примитивному типу. В частности, зто означает, что тип 
достаточно простои и у него нет членов, ciioco6iii,ix изменитв зкземплнрнБ1е 
полн типа, в зтом случае говорнт, что тип неизменлемип (immutable). На самом 
деле, многие значимвге типб 1 рекомендуетсн помечатк спецификатором readonly 
(см. главу 7). 

□ Тип не обизан иметв лгобои другои тип в качестве базового. 

□ Тип не имеет производнвш от него типов. 

Также необходимо учитвшатв размер зкземплнров типа, потому что по умолча- 
ниго аргументБ 1 передаготсл по значениго; при зтом полн зкземплиров значимого 
типа копируготсл, что отрицателвно сказБшаетсл на производителБности. ПовторгосБ: 
длн метода, возвравдаговдего значимвп! тип, полн зкземплнра копируготсн в памитв, 
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вмделеннуго вмзмваклцим кодом в месте возврата из метода, что снижает зффектив- 
ностб работм программм. Позтому в дополнение к перечисленнмм условинм следует 
о6ђнвлнтб тип как значимми, если верно хотн бм одно из следукицих условии: 

□ Размер зкземплнров типа мал (примерно 16 баит или менБше). 

□ Размер зкземплнров типа велик (более 16 баит), но зкземплнрм не передаготси 
в качестве параметров метода или не ивлиготсл возвратцаеммми из метода зна- 
чениими. 

Основное достоинство значиммх типов в том, что они не разметцаготси в управ- 
лиемои куче. Конечно, в сравнении со ссмлочнмми типами у значиммх типов естћ 
недостатки. Важнеишие отличиц между значиммми и ссмлочнмми типм: 

□ ОбЂектм значимого типа сугцествугот в двух формах (см. следугогции раздел): 
неупакованноп (unboxed) и упакованноп (boxed). Ссмлочнме типм бмвагот толђко 
в упакованнои форме. 

□ Значимме типм нвлнготси производнмми от System . ValueType. Зтот тип имеет 
тежеметодм,что и System.Object. Однако System.ValueType переопределлет 
метод Equals, которми возврагцает tnue, если значенгш полеи в обоих обљектах 
совпадагот. Крометого, в System.ValueType переопределенметод GetHashCode, 
которми создает хеш-код по алгоритму, учитмвагогцему значенгш полеи зкзем- 
плнра обвекта. Из-за проблем с производителЂностЂго в реализации по умол- 
чаниго, определии собственнме значимме типм значении, надо переопределитЂ 
и написатЂ свого реализациго методов Equals и GetHashCode. О методах Equals 
и GetHashCode рассказано в конце зтои главм. 

□ ПосколЂку в обЂнвлении нового значимого или ссмлочного типа нелЂЗи указм- 
ватБ значимми тип в качестве базового класса, создаватЂ в значимом типе новме 
виртуалЂнме методм нелЂЗл. Методм не могут 6мтђ абстрактнмми и нелвно 
ивлиготсл запечатаннмми (то еств их нелвзи переопределитЂ). 

□ Переменнме ссмлочного типа содержат адреса обвектов в куче. Когда пере- 
меннаи ссмлочного типа создаетсл, еи по умолчаниго присваиваетсл null, то 
еств в зтот момент она не указмвает на деиствителвнми обвект. Попмтка за- 
деиствоватв переменнуго с таким значением приведет к генерации исклгоченгш 
NullReferenceException. В то же времн в переменнои значимого типа всегда 
содержитсл некое значение соответствугогцего типа, а при инициализации 
всем членам зтого типа присваиваетсл 0. Посколвку переменнаи значимого 
типа не лвлнетсл указателем, при обрагцении к значимому типу исклгочение 
NullReferenceException возникнутв не может. CLR поддерживает понитие 
значимого типа особого вида, допускагогцего присваивание null (nullable types). 
Зтот тип обсуждаетсл в главе 19. 

□ Когда переменнои значимого типа присваиваетсн друган переменнаи значимого 
типа, вмполниетсл копирование всех ее полеи. Когда переменнои ссмлочно- 



CcbmoHHbie и значимне типн 155 


го типа присваиваетсл переменнап ссмлочного типа, копируетсл толбко ее 
адрес. 

□ Вследствие сказанного в предмдугцем пункте несколћко переменнмх ссмлочного 
типа могут ссмлатБСи на один обвект в куче, благодарн чему, работал с однои 
переменнои, можно изменитБ обвект, на которћпг ссншаетсл другаи переменнан. 
В то же времл каждал переменнан значимого типа имеет собственнуго копиго 
даннБ1Х <<обБекта», позтому операции с однои переменнои значимого типа не 
влгшгот на другуго переменнуго. 

□ Так как неупакованнвге значимБге t ihii.i не размегцаготсл в куче, отведеннан длл 
них памнтв освобождаетсл сразу при возврагцении управленин методом, в кото- 
ром описан зкземплир зтого типа (в отличие от ожиданин уборки мусора). 


Как CLR управллет размеидением полеи длл типа 

Дли повБ1шенгш производителБности CLR дано право устанавливатв порндок 
размегценгш полеи типа. Например, CLR может вБгстроитБ полл таким образом, 
что ссбглки на обвектБг окажутсл в однои группе, а полн даннвгх и своиства — вбг- 
ровненнБге и упакованнБге — в другои. Однако при описании типа можно указатв, 
сохранитБ ли порлдок полеи данного типа, определеннБги программистом, или 
разрешитБ CLR вбгполнитб зту работу. 

Длн того что6бг сообгцитБ CLR способ управленин полнми, укажите в описании 
классаилиструктурвг атрибут System.Runtime.InteropServices .StructLayout- 
Attribute. Чтобвг порлдок полеи устанавливалси CLR, нужно передатв конструк- 
тору атрибута параметр LayoutKind . Auto, чтобкг сохранитБ установленнБги про- 
граммистом порндок — параметр LayoutKind . Sequential, а параметр LayoutKind . 
Explicit позволлет разместитв полн в памлти, нвно задав смегценгш. Если в опи- 
сании типа не применен атрибут StructLayoutAttribute, порндок полеи ввгберет 
компилнтор. 

Длн ссбглочнбгх тггпов (классов) компилнтор C# вБгбирает вариант LayoutKind . 
Auto, а длл значимвгх типов (структур) — LayoutKind . Sequential. Очевггдно, раз- 
работчикгг компилнтора считагот, что структурвг обвгчно исполвзуготсн длл взагг- 
модеиствин с неуправлиемвгм кодом, а значит, полн нужно расположитк так, как 
определено разработчггком. Однако пргг созданигг значимого типа, не работагогцего 
совместно с неуправлнемвгм кодом, скорее всего, поведенгге компилнтора, пред- 
лагаемое по умолчанггго, потребуетсл изменитв, например: 

using System; 

using System.Runtime.InteropServices; 

// Дла повишенил производителБности разрешим CLR 
// установитБ порлдок полеи длл зтого типа 
[StructLayout(LayoutKind.Auto) ] 
internal struct SomeValType { 
private readonly Byte m_b; 


продолжение & 
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private readonly Intl 6 m_x; 


} 


Атрибут StructLayoutAttnibute также позволлет лвно задатБ смешение дли 
всех полеи, передав в конструктор LayoutKind . Explicit. Затемможно применитБ 
атрибут System . Runtime . InteropServices . FieldOf f setAttribute ко всем полим 
путем передачи конструктору зтого атрибута значенип типа Int32, определнгогцего 
смегцение (в баитах) первого баита поли от начала зкземплира. И нпос размегцение 
о 6 б 1 чно исполБзуетсл длл имитации того, что в неуправлчемом коде на С/С++ 
назБшалосв обЂединением (union), то естБ размегценгш несколБКих полеи с одного 
смегценгш в памнти, например: 

using System; 

using System.Runtime.InteropServices; 

// Разработчик пвно задает порпдок полеи в значимом типе 
[StructLayout(LayoutKind . Explicit) ] 
internal struct SomeValType { 

[FieldOffset(0)] 

private readonly Byte m_b; // Полл m_b и m_x перекртвак)тсл 
[FieldOffset(0)] 

private readonly Intl 6 m_x; // в зкземплврах зтого класса 

} 


Не допускаетсн определение типа, в котором перекрБгваготсн ссбглочнбги и значи- 
мбги типбг. Можно опрсдслитБ тип, в котором перекрБгваготси несколБКО значимБгх 
типов, однако все перекрБгвагогциесн баитБг должнбг 6бгтб доступнБг через открБгтБге 
поли, что6бг обеспечитБ верификациго типа. 


Упаковка и распаковка значиммх типов 

ЗначимБге типбг «легче» ссбглочнбгх: длл них не нужно вбгдслнтб памнтБ в управ- 
лнемои куче, их не затрагивает сборка мусора, к ним нелвзи обратитБСл через 
указателБ. Однако часто требустсм получатБ ссбглку на зкземплнр значимого типа, 
например если вбг хотите сохранитБ структурБг Point в обвекте типа ArrayList 
(определен в пространстве имен System.Collections). В коде зто вбггллдит при- 
мерно следугогцим образом: 

// ОбБВВллем значимти тип 
struct Point { 

public Int32 х, у; 

} 


public sealed class Program { 
public static void Main() { 
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AmayList а = new ArrayList(); 

Point р; // Внделлетсн памлтБ длл Point (не в куче) 

for (Int32 i = 0; i < 10; i++) { 

р.х = р.у = i; // Инициализацил членов в нашем значимом типе 
a.Add(p); // Упаковка значимого типа и добавление 

// ссмлки в ArrayList 

} 


} 

} 

В каждои итерации цикла инициализируготсн полн значимого типа Point, после 
чего Point помегцаетси в ArrayList. Задумаемси, что же помегцаетсл в ArrayList: 
сама структура Point, адрес структурм Point или что-то иное? За ответом обратимсн 
к методу Add типа Аггау List и посмотрим описание его параметра. В данном случае 
прототип метода Add вмглидит следугогцим образом: 

public virtual Int32 Add(Object value); 

Отсгода видно, что в параметре Add должен передаватБСл тип Object, то естБ 
ссБшка (или указателк) на оођскт в управлнемои куче. Однако в примере л передаго 
переменнуго р, имегогцукз значимвш тип Point. Что6б1 код работал, нужно преобразо- 
ватБ значимБш тип Point в оођскт из управлнемои кучи и получитв на него сспшку. 

Дли преобразовангш значимого типа в ссбшочнбш служит упаковка (boxing). 
При упаковке зкземплира значимого типа происходит следугогцее. 

1. В управлиемои куче вБвделиетсл памнтБ. Ее обвем определлетсл длинои значи- 
мого типа и двумл дополнителБНБши членами — указателем на типовои обпект 
и индексом блока синхронизации. Зти членБ1 необходимБ1 дли всех обБектов 
в управлнемои куче. 

2. Полн значимого типа копируготсн в памнтв, толбко что вБгделеннуго в куче. 

3. Возврагцаетсл адрес обвекта. Зтот адрес лвлнетсн ссбшкои на обвект, то естн 
значимБпг тип преврагцаетсл в ссбшочнбш. 

Компиллтор C# создает IL -код, необходимнш длл упаковки зкземплира значи- 
мого типа, автоматически, но bbi должнб1 пониматБ, что происходит «за кулисами» 
и помнитб об опасности «распухании» кода и сниженгш производителБности. 

В предБгдугцем примере компшштор C# обнаружил, что методу, требугогцему 
ссБглочнБш тип, в иараметре передаетсл значимБги тип, и автоматически создал код 
длл упаковки обвекта. Вследствие зтого полн зкземплира р значимого типа Point 
в период вБгполненгш копируготсл во вновб созданнБги в куче обвект Point. Полу- 
ченнБги адрес упакованного обвекта Point (теперв зто ссбглочнбги тип) передаетсл 
методу Add. Обвект Point остаетсл в куче до очереднои уборки мусора. Перемен- 
нуго р значимого тггпа Point можно исполБЗОватБ повторно, так как ArrayList ничего 
о неи не знает. Заметвте: времи жизни упакованного значимого типа преввгшает 
времн жизни неупакованного значимого типа. 
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ПРИМЕЧАНИЕ 

В состав FCL входит новое множество обобш,еннмх классов коллекции, из-за котори 1 х 
необоб 1 деннме классн коллекции считакзтсл устаревшими. Так, вместо класса System. 
Collections.ArrayList следует исполизоватв класс System.Collections.Generic.List<T>. 
Обобиденнме класси! коллекции во многих отношенилх совершеннее своих необоб- 
иденнмханалогов. В частности, API -интерфеис стал лснее и совершеннее, кроме того, 
повмшена производителвноств классов коллекции. Но одно из самих ценнихулучше- 
нии заклкзчаетсл в предоставллемои обобиденнмми классами коллекции возможности 
работатв с коллекцилми значимнхтипов, не прибегал к ихупаковке/распаковке. Одна 
зта особенности позволлет значителино noBbicnTb производителБностБ, так как ра- 
дикалвно сокраидаетсл число создаваеммх в управлиемои куче обЂектов, что, в свокз 
очереди, сокраидает число проходов сборидика мусора в приложении. В резулвтате 
обеспечиваетсл безопасноститипов назтапе компиллции, а код становитсч понлтнее 
за счет сокраиденил числа приведении типов (см. главу 12). 


ПознакомившисБ с упаковкои, переидем к распаковке. Допустим, в другом месте 
кода нужно извлечБ первши злемент массива ArrayList: 

Point р = (Point) а[0]; 

Здссб ссмлка (или указателћ), содержагцапси в злементе с номером 0 массива 
ArrayList, помегцаетсл в переменнукз р значимого типа Point. Длн зтого все полн, 
содержагциесн в упакованном обвекте Point, надо скопироватБ в переменнукз р 
значимого типа, находигцукзсн в стеке потока. CLR вмполннет зту процедуру в два 
.зтапа. Сначала извлекаетсн адрес полеи Point из упакованного обвекта Point. Зтот 
процесс назмвакзт распаковкоп (unboxing). Затем значенич полеи копирукзтси из 
кучи в зкземплнр значимого типа, находигцииси в стеке. 

Распаковка не нвлиетси точнои противоположностБкз упаковки. Она гораздо 
менее ресурсозатратна, чем упаковка, и состоит толбко в получении указатели на 
исходнми значимБди тип (полн даннмх), содержагциисн в обвекте. В сугцности, 
указателћ ссмлаетсн на неупакованнуго частг> упакованного зкземплнра, и никакого 
копировангш при распаковке (в отличие от упаковки) не требуетси. Однако вслед 
за распаковкои обћдчно вБшолннетсн копирование полеи. 

Понитно, что упаковка и распаковка/копирование снижагот производителБ- 
ностб приложешш (в плане как замедленгш, так и расходовангш дополнителвнои 
памити), по.зтому нужно знатн, когда компилнтор сам создает код длн вБшолненгш 
зтих операции, и старатнси свести их к минимуму. 

При распаковке упакованного значимого типа происходит следугогцее. 

1. Если переменнан, содержагцан ссвшку на упакованнБпг значимБги тип, равна 
null, генерируетси исклгочение NullReferenceException. 

2. Если ссвшка указкшает на обвект, не нвлчгогциисн упакованнвгм значением 
требуемого значимого типа, генерируетсл исклгочение InvalidCastException'. 


1 CLR также позволлет распаковшватБ значимвге типбг в версикз зтого же типа, поддержи- 
вакзпдукз присвоение значении null (см. главу 19 ). 
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Из второго пункта следует, что приведеннши ниже код не работает так, как 
хотслос!) бм: 

public static void Main() { 

Int32 х = 5; 

Object o = х; // Упаковка х; o указмвает на упакованнми обиект 

Intl6 у = (Intl6) о; // Генерируетсл InvalidCastException 

} 


Казалосв бм, можно взнтб упакованнми зкземплир Int32, на которми указм- 
вает о, и привести к типу Intl6. Однако при распаковке обвекта должно 6 мтб вм- 
полнено приведение к неупакованному типу (в нашем случае — к Int32). Вот как 
вмгллдит правилБнми вариант: 

public static void Main() { 

Int32 х = 5; 

Object o = х; // Упаковка х; o указнвает на упакованнни обвект 
Intl6 у = (Intl6)(lnt32) о; // Распаковка, а затем приведение типа 

} 


Как 'А уже отмечал, распаковка часто сопровождаетсл копированием полеи. 
Следугогции код на C# демонстрирует, что операции распаковки и копированин 
часто работагот совместно: 

public static void Main() { 

Point p; 
р.х = р.у = 1; 

Object o = p; // Упаковка p; o указмвает на упакованнми обиект 
р = (Point) о; // Распаковка о и копирование полеи из зкземплвра в стек 

} 


В последнеи строке компиллтор C# генерирует IL -команду длл распаков- 
ки о (получение адреса полеи в упакованном зкземплнре) и егце одну IL -команду 
дли копировангш полеи из кучи в переменнуго р, располагагогцугосн в стеке. 
ТеперБ посмотрите на следугогции пример: 

public static void Main() { 

Point p; 
р.х = р.у = 1; 

Object o = p; // Упаковка p; o указивает на упакованнии зкземпллр 

// Изменение полл х структурм Point (присвоение числа 2). 
р = (Point) о; // Распаковка о и копирование полеи из зкземпллра 
// в переменнук) в стеке 

р.х = 2; // Изменение состолнин переменнои в стеке 
о = р; // Упаковка р; о ссмлаетсл на новми упакованнми зкземпллр 

} 


Во второи части примера нужно изменитБ поле х структурм Point с 1 на 2. Длн 
зтого вмполннгот распаковку, копирование полеи, изменение полн (в стеке) и упа- 
ковку (создагогцуго новми обвект в управлнемои куче). Веронтно, вм понимаете, что 
все зти операции обизателБно сказмваготси на производителБности приложенгш. 
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В некотормх измках, например в C++/CLI, разрешаетсн распаковатБ упакован- 
нми значимми тип, не копирун полн. Распаковка возврашдет адрес неупакованнои 
части упакованного обвекта (дополнителБнме членм — указателБ на типовои обвект 
и индекс блока синхронизации — игнорируготсн). Затем, исполБзун полученнми 
указателћ, можно манипулироватћ полнми неупакованного зкземплнра (которми 
находитсн в упакованном обвекте в куче). Например, реализацин приведенного 
вмше кода на C++/CLI сугцественно повмсит его производителБностБ, потому что 
вб1 можете изменитБ значение полн х структурБг Point в уже упакованном зкзем- 
плнре Point. Зто позволит избежатв как вБгделенгш памлти длл нового обвекта, 
так и повторного копированин всех полеи! 

ВНИМАНИЕ 

Если Bbi хотл 6bi в малеишеи степени заботитесв о производителвности своего 
приложенич, вам необходимо знати, когда компиллтор создает код, ввтолнл 101 ции 
зтиоперации. Ксожаленикз, многие компиллторм нелвно генерирукзт кодупаковки, 
позтому иногда би 1 вает сложно узнати о происходлидеи упаковке. Если менл деистви- 
телино волнует производителиноств приложенил, л прибегакз ктакому инструменту, 
как ILDasm.exe, просматривак) IL -код готовмх методов и смотркз, присутствукзт ли 
в нем командм упаковки. 


Рассмотрим егце несколвко примеров, демонстриругогцих упаковку и распа- 
ковку: 

public static void Main() { 

Int32 v = 5; // Создание неупакованнои переменнои значимого типа о 

Object о = v; // указмвает на упакованное Int32, содержацее 5 
v = 123; // Изменнем неупакованное значение на 123 

Console.WriteLine(v + ", " + (Int32) о); // Отображаетсп "123, 5" 

} 

Сколбко в зтом коде операции упаковки и распаковки? Вбг не поверите — целвгх 
три! РазобратБСл в том, что здесв происходит, нам поможет IL -код метода Main. 
Что6бг бБгстрее наити отделБНБге операции, н снабдил распечатку комментаргшми. 

.method public hidebysig static void Main() cil managed 

{ 

.entnypoint 

// Размер кода 45 (0x2d) 

.maxstack 3 

.locals init ([0]int32 v, 

[1] object o) 

// Загружаем 5 в v. 

IL_0000: ldc.i4.5 

IL_0001: stloc.0 

// Упакуем v и сохранпем указателв в о. 

IL 0002: ldloc.0 
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IL_00@3: box [mscorlib]System.Int32 

IL_0008: stloc.l 

// Загружаем 123 в v. 

IL_0009: ldc.i4.s 123 

IL_000b: stloc.0 

// Упакуем v и сохранвем в стеке указателв длл Concat 
IL_ 000 c : ldloc .0 

IL_000d: box [mscorlib]System.Int32 

// Загружаем строку в стек длл Concat 
IL_ 0012 : ldstr ", " 

// Распакуем o: берем указатели в поле Int32 в стеке 
IL_0017 : ldloc.l 

IL_0018: unbox.any [mscorlib]System.Int32 

// Упакуем Int32 и сохранлем в стеке указатели длн Concat 
IL_001d: box [mscorlib]System.Int32 

// Внзмваем Concat 

IL_0022: call string [mscorlib]System.String::Concat(object, 

object, 

object) 


// Строку, возвратеннук) из Concat, передаем в WriteLine 

IL_0027: call void [mscorlib]System.Console::WriteLine(string) 

// Метод Main возвратает управление, и приложение завершаетсл 
IL_002c: ret 

} // Конец метода App::Main 

Вначале в стеке создаетсл зкземплнр v неупакованного значимого типа Int32, 
которому присваиваетсл число 5. Затем создаетсл переменнаи о типа Object, кото- 
раи инициализируетсл указателем на v. Однако посколбку ссБшочнБ 1 е типб 1 всегда 
должнб 1 указБ 1 ватБ на обвектБ 1 в куче, C# генерирует соответствугогции IL -код 
длл упаковки v и заносит адрес упакованнои «копии» v в о. Теперв величина 123 
помегцаетсл в неупакованнвп! зпачи.чњш тип v, но зто не влинет на упакованное 
значение типа Int32, которое остаетси равнвш 5. 

ДалБше вБ 13 Б 1 ваетсл метод WriteLine, которому нужно передатв обвект Stning, 
но такого обвекта нет. Вместо строкового обњекта mbi имеем неупакованнвп! зк- 
земплнр значимого типа Int32 (v), обвект Stning (ссбшочного типа) и ссншку на 
упакованнБп! зкземплнр значимого типа Int 32 (о), которкш приводитсл к неупа- 
кованному типу Int32. Зти злементБ1 нужно как-то обвединитБ, что 6 б 1 получилсч 
обвект Stning. 

Что6б 1 создатБ Stning, компилнтор C# формирует код, в котором ввгоБшаетси 
статическии метод Concat обвекта Stning. Естб несколБКО перегруженнБ1х версии 
зтого метода, различагогцихсл лишб количеством параметров. Посколвку строка 
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формируетсл путем конкатенации трех злементов, компилнтор вмбирает следуго- 
myio версиго метода Concat: 

public static String Concat(Object arg0, Object argl, Object arg2); 

B качестве первого параметра, arg0, передаетсл v. Но v — зто неупакованное 
значение, а arg0 — зто значение Object, позтому зкземплир v нужно упаковатБ, 
а его адрес передатБ в качестве arg0. Параметром argl нвлнетсл строка ", ” в виде 
ссбшки на обгБСкт String. И наконец, что 6 б 1 передатБ параметр arg2, о (ссБшка на 
Object) приводитсн к типу Int32. Длн зтого нужна распаковка (но без копирова- 
нгш), при которои извлекаетсл адрес неупакованного зкземшшра Int32 внутри 
упакованного зкземплнра Int32. Зтот неупакованнвш зкземплнр Int32 надо опнтб 
упаковатБ, а его адрес в памлти передатв в качестве параметра arg2 методу Concat. 

Метод Concat ввгоБшает методБ1 ToString длн каждого указанного обвекта и вбн 
полниет конкатенациго строковБ1х представлении зтих обвектов. ВозврагцаемБ1и 
из Concat обвект String передаетсл затем методу WriteLine, которкш отображает 
окончателБНБп! резулнтат. 

ПолученнБнг IL -код станет зффективнее, если обрагцение к WriteLine пере- 
писатв: 

Console.WriteLine(v + ", " + о); // Отображаетсл "123, 5" 

Зтот вариант строки отличаетсн от предвгдугцего толбко отсутствием длн пере- 
меннои о операцгш приведенгш типа (Int32). Зтот код ввшолннетсл бБгстрее, так 
как о уже лвлиетсл ссбглочнбш типом Object и его адрес можно сразу передатн 
методу Concat. ОтказавшисБ от приведенгш типа, н избавилсн от двух операции: 
распаковки и упаковки. В зтом легко убедитвсл, если заново собратв приложение 
и посмотретБ на сгенерированнБш IL -код: 

.method public hidebysig static void Main() cil managed 

{ 

.entrypoint 

// Размер кода 35 (0x23) 

.maxstack 3 

.locals init ([0] int32 v, 

[ 1 ] object o) 

// Загружаем 5 в v 
IL_0000: ldc.i4.5 

IL_ 0001 : stloc .0 

// Упакуем v и сохранлем указателБ в о 
IL_ 00 @ 2 : ldloc .0 

IL_0003: box [mscorlib]System.Int32 

IL_ 00 @ 8 : stloc.l 

// Загружаем 123 в v 
IL_0009: ldc.i4.s 123 
IL 000b: stloc.0 
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// Упакуем v и сохранлем в стеке указатели длл Concat 
IL_000c : ldloc.0 

IL_000d: box [mscorlib]System.Int32 

// Загружаем строку в стек длл Concat 
IL_0012 : ldstr ", " 

// Загружаем в стек адрес упакованного Int32 длл Concat 
IL_0017 : ldloc.l 

// Внзмваем Concat 

IL_0018: call string [mscorlib]System.String::Concat(object, 

object, 

object) 


// Строку, возвратеннук) из Concat, передаем в WriteLine 

IL_001d: call void [mscorlib]System.Console::WriteLine(string) 

// Main возвратает управление, чем завершаетсл работа приложенил 
IL_0022 : ret 

} // Конец метода App::Main 

Беглое сравнение двух версии IL -кода метода Main показмвает, что вариант без 
приведенгш типа Int32 на 10 баит менћше, чем вариант с приведением типа. До- 
полнителБнме операции распаковки/упаковки, безусловно, приводлт к разрастаншо 
кода. Если мм поидем далћше, то увидим, что зти операции потребугот вБвделенгш 
памнти в управлнемои куче длн дополнителБного обвекта, которуго в будугцем дол- 
жен освободитБ уборгцшс мусора. Конечно, обе версии приводлт к одному резулкгату 
и разница в скорости незаметна, однако лишние операции упаковки, вмполннемме 
многократно (например, в цикле), могут заметно повлгштб на производителг>ностг, 
приложенгш и расходование памлти. 

ПредБгдугции код можно улучшитБ, изменив вбгзов метода WriteLine: 

Console.WriteLine(v.ToString() + ", " + о); // Отображаетсл "123, 5" 

Длн неупакованного значимого типа v теперБ вБгзБгваетсл метод ToString, воз- 
врагцагогции String. Строковвге обвектБг нвлнготсн ссбглочнбгми типами и могут 
легко передаватБСн в метод Concat без упаковки. 

Вот егце один пример, демонстриругогции упаковку и распаковку: 

public static void Main() { 

Int32 v = 5; // Создаем неупакованнук) переменнуш значимого типа 

Object о = v; // о указшвает на упакованнуш версик) v 

v = 123; // Изменлет неупакованнми значимми тип на 123 

Console.WriteLine(v); // Отображает "123" 

v = (Int32) о; // Распаковмвает и копирует о в v 

Console.WriteLine(v); // Отображает "5" 

} 
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Сколбко операции упаковки ви насчитали в зтом коде? ПравилБно — одну. 
Дело в том, что в классе System.Console описан метод WriteLine, принимакнции 
в качестве параметра тип Int32: 

public static void WriteLine(Int32 value); 


B показаннмх ранее вмзовах WriteLine переменнан v, имекшдан неупакованнми 
значимми тип Int32, передаетси по значеншо. Возможно, где-то у себн WriteLine 
упакует зто значение Int32, но тут уж ничего не поделаешм Главное — мм сделали 
то, что от нас зависело: убрали упаковку из своего кода. 

ПристалБно взглинув на FCL, можно заметитБ, что многие перегруженнБ1е ме- 
тодб 1 исполБзугот в качествс параметров значимвге типбк Так, тип System . Console 
предлагает несколкко перегруженнБ1х вариантов метода WriteLine: 


public static void 
public static void 
public static void 
public static void 
public static void 
public static void 
public static void 
public static void 
public static void 
public static void 
public static void 
public static void 


WniteLine(Boolean); 
WniteLine(Chan); 
WriteLine(Char[]); 
WriteLine(Int32); 
WriteLine(UInt32); 
WriteLine(Int64); 
WriteLine(UInt64); 
WriteLine(Single); 
WriteLine(Double); 
WriteLine(Decimal); 
WriteLine(Object); 
WriteLine(String); 


Аналогичнвш набор перегруженшлх версии еств у метода Write типа System. 
Console, у метода Write типа System . 10. BinaryWriter, у методов Write и Write- 
Line типа System. IO.TextWriter, у метода AddValue типа System.Runtime . Se- 
rialization.Serializationlnfo, у методов Append и Insert типа System.Text. 
StringBuilder и т. д. Болбшинство зтих методов имеет перегруженнвш версии 
толбко затем, что6б1 уменБшитБ количество операции упаковки длн наиболее часто 
исполвзуемБ1х значимБ1х типов. 

Если вб 1 определите собственнБп) значимБ1и тип, у зтих FCL -классов не будет 
соответствугогцеи перегруженнои версии длл вашего типа. Более того, длл рнда 
значимБ1х типов, уже сугцествугогцих в FCL, нет перегруженнБ1х версии указан- 
нб 1 х методов. Если ввгоБшатБ метод, у которого нет перегруженнои версии длл 
передаваемого значимого типа, резулвтат в конечном итоге будет один — вбгоов 
перегруженного метода, принимагогцего Object. Передача значимого типа как 
Object приведет к упаковке, что отрицателвно скажетсл на производителБности. 
Определнн собственнБп) класс, можно задатк в нем обобгценнвге методБ1 (возможно, 
содержагцие параметрБ1 типа, которвге ивлнготсн значимвши типами). Обобгценгш 
позволнгот определитБ метод, принимагогции лгобои значимБги тип, не требун при 
зтом упаковки (см. главу 12). 

И последнее, что касаетсн упаковки: если вбг знаете, что ваш код будет периоди- 
чески заставлитв компилитор упаковБгватБ какои-то значимБги тип, можно уменБ- 
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шитб о6б6м и ПОВБ1СИТБ бБГСтродеиствие своего кода, вбшолнив упаковку зтого типа 
вручнуго. Взглнните на следугогции пример. 

using System; 

public sealed class Program { 
public static void Main() { 

Int32 v = 5; // Создаем переменнуи) упакованного значимого типа 
#if INEFFICIENT 

// При компилнции следутшеи строки v упакуетсн 
// три раза, расходун и времл, и памнтц 
Console.WriteLine("{0}, {1}, {2}", v, v, v); 

#else 

// Следутшие строки датт тот же резулцтат, 

// но внполннттсл намного бнстрее и расходутт менцше памнти 
Object о = v; // Упакуем вручнут v (толбко единождм) 

// При компиллции следутшеи строки код упаковки не создаетсн 
Console.WriteLine("{0}, {1}, {2}", о, о, о); 

#endif 

} 

} 

Если компилироватБ зтот код с определеннБш символическим именем 
INEFFICIENT, КОМПИЛЛТОр создаст КОД, ТрИЖДБ1 ВБ1ПОЛНИГОГЦИИ упаковку V И ВБ1- 
делнгогции памнтБ в куче длл трех обвектов! Зто особенно расточителвно, так как 
каждБги обвект будет содержатк одно значение — 5. Если же компилироватБ код без 
определенгш символа INEFFICIENT, значение v будет упаковано толбко раз и толбко 
один обвект будет размегцен в куче. Затем при обрагцении к Console.WniteLine 
триждвг передаетсл ссншка на один и тот же упакованнБш обвект. Второи вариант 
вБшолннетсн нампого бнгстрее и расходует меннше памнти в куче. 

В зтих примерах доволбно легко определитБ, где нужно упаковатБ зкземплнр 
значимого типа. Простое правило: если нужна ссвшка на зкземплнр значимого типа, 
зтот зкземплнр должен 6бгтб упакован. Обвшно упаковка ввшолннетсл, когда надо 
передатБ значимБш тип методу, требугогцему ссбшочнбш тип. Однако могут 6бгтб 
и другие ситуации, когда требустсм упаковатк зкземплнр значимого типа. 

Помните, мб1 говоргши, что неупакованнвге значимБге типбг «легче» ссбшочнбгх, 
посколБку: 

□ памнтБ в управлнемои куче им не ввгделлетсл; 

□ у них нет дополнителБНБгх членов, присугцих каждому обвекту в куче: указателн 
на типовои обвект и индекса блока синхронизации. 

Посколвку неупакованнБге значимБге типбг не имегот индекса блока синхрони- 
зации, то не может 6бгтб и несколБКих потоков, синхронизиругогцих свои доступ 
к зкземплнру через методвг типа System.Threading .Monitor (гши инструкцгш lock 
изБгка С#). 
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Хотн неупакованнме значимме типм не hmciot указателн на типовои обвект, вм 
все равно можете вмзмватБ виртуалБНБге методБ1 (такие, как Equals, GetHashCode 
или ToStning), унаследованнБге или прееопределеннБге зтим типом. Если ваш зна- 
чимбш тип переопределлет один из зтих виртуалБНБ1х методов, CLR может ввиватБ 
метод невиртуалБно, потому что значимБШ типб1 ненвно запечатБшаготсн и позтому 
не могут ББ1СтупатБ базовБши классами других типов. Кроме того, зкземплнр зна- 
чимого типа, исполвзуемвш дли iii.isona виртуалБного метода, не упаковБшаетсл. 
Но если ваше переопределение виртуалвного метода ввшБшает реализациго зтого 
метода из базового типа, зкземплир значимого типа упаковвшаетсл при вБ 130 ве 
реализации базового типа, чтобв1 в указателе this базового метода передаваласв 
ссвшка на обвект в куче. 

Вместе с тем вбгоов невиртуалвного унаследованного метода (такого, как GetType 
или MemberwiseClone) всегда требует упаковки значимого типа, так как зти методБ1 
определенБ1 в System . Ob ј ect, позтому методБ1 ожидагот, что в аргументе this пере- 
даетсн указателв на обвект в куче. 

Кроме того, приведение неупакованного зкземплира значимого типа к одному 
из интерфеисов зтого типа требует, что6б1 зкземплнр 6б1л упакован, так как ин- 
терфеиснвге переменнБШ всегда должнб1 содержатБ ссбшку на обвект в куче. (Об 
интерфеисах см. главу 13 .) Сказанное иллгострирует следугогции код: 

using System; 

internal struct Point : IComparable { 
private Int32 m_x, m_y; 

// Конструктор, просто инициализируклции полн 
public Point(Int32 х, Int32 у) { 
m_x = х; 

m_y = у; 

} 

// Переопределлем метод ToString, унаследованнми от System.ValueType 
public override String ToStringO { 

// Возврашаем Point как строку (вузов ToString предотвратает упаковку) 
return String.Format ("({0}, {1})", m_x.ToString(), m_y.ToString()); 

} 

// Безопаснал в отношении типов реализацил метода CompareTo 
public Int32 CompareTo(Point other) { 

// Исполцзуем теорему Пифагора длл определенил точки, 

// наиболее удаленнои от начала координат (0, 0) 
return Math.Sign(Math.Sqrt(m_x * m_x + m_y * m_y) 

- Math.Sqrt(other.m_x * other.m_x + other.m_y * other.m_y)); 

} 

// Реализацин метода CompareTo интерфеиса IComparable 
public Int32 CompareTo(Object o) { 
if (GetType() != o.GetType()) { 
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throw new ArgumentException("o is not a Point"); 

} 

// BbBOB безопасного в отношении типов метода CompareTo 
return CompareTo((Point) o); 

} 


public static class Program { 
public static void Main() { 

// Создаем в стеке два зкземплнра Point 
Point pl = new Point(10j 10); 

Point p2 = new Point(20j 20); 

// pl HE пакуетсл длн внзова ToString (виртуалвнни метод) 
Console.WriteLine(pl.ToStringQ); // "(10j 10)" 

// pl ПАКУЕТСВ длл внзова GetType (невиртуалннми метод) 

Console.WriteLine(pl.GetType() ); // "Point" 

// pl HE пакуетсл дли внзова CompareTo 

// p2 HE пакуетслЈ потому что вћвван CompareTo(Point) 

Console.WriteLine(pl.CompareTo(p2)); // "-1" 

// pl ПАКУЕТСВ j a ссмлка размешаетсл в c 
IComparable c = pl; 

Console.WriteLine(c.GetType()); // "Point" 

// pl HE пакуетсл длл внзова CompareTo 

// Посколику в CompareTo не передаетсл переменнал Point, 

// вћ13нваетсл CompareTo(Object) , которому нужна сснлка 
// на упакованнни Point 

// с HE пакуетсл, потому что уже ссилаетсл на упакованнми Point 
Console.WriteLine(pl.CompareTo(c) ); // "0" 

// с HE пакуетсн, потому что уже сснлаетсн на упакованнми Point 
// р2 ПАКУЕТСВ, потому что BbBbiBaeTCH CompareTo(Object) 

Console.WriteLine(c.CompareTo(p2) );// "-1" 

// c пакуетсл, a поли копируттсл в p2 
p2 = (Point) c; 

// Убеждаемсл, что полл скопирован^ в р2 
Console.WriteLine(p2.ToString());// "(10, 10)" 

} 


В зтом примере демонстрируетси сразу несколБКО сценариев поведенин кода, 
свнзанного с упаковкои/распаковкои. 

□ Вмзов ToString. При вмзове ToStning упаковка pl не требуетсл. Казалосв бм, 
тип Pl должен 6 мтб упакован, так как Т oStning — метод, унаследованнми от ба- 
зового типа, System . ValueType. Обмчно дли вмзова виртуалБного метода нужен 
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указателћ на типовои обвект, а посколБку pl нвлнетсл неупакованнмм значиммм 
типом, то нет ссмлки на типовои обвект Point. Однако JIT -компилнтор видит, 
что метод ToStning переопределен в Point, и создает код, которми напрнмуго 
(невиртуалБно) вмзмвает ToStning. Компилнтор знает, что полиморфизм здесБ 
невозможен, колб скоро Point ивлнетсл значимћш типом, а значимнге типб 1 не 
могут применитБСн дли другого типа в качестве базового и по-другому реали- 
зоввшатБ виртуалБНБш метод. Ели 6 б 1 метод ToStning из Point во внутреннеи 
реализации ввгоБшал base.ToStning(), то зкземплир значимого типа 6 бш 6 б 1 
упакован при ввгоове метода ToStning типа System.ValueType. 

□ Вбгоов GetType. При вБГООве невиртуалвного метода GetType упаковка pl не- 
обходима, посколвку тип Point не реализует GetType, а наследует его от System . 
Object. Позтому длн внгоова GetType нужен указателв на типовои обвект Point, 
которвп! можно получитв толбко путем упаковки pl. 

□ ПервБШ вбгоов CompareTo. При первом ввгоове CompaneT о упаковка pl не нужна, 
так как Point реализует метод CompaneTo, и компилнтор может просто ввговатв его 
напрнмуго. ЗаметБте: в CompaneTo передаетсл переменнан р2 типа Point, позтому 
компилитор ввгоБшает перегруженнуго версиго CompaneTo, котораи принимает 
параметр типа Point. Зто означает, что р2 передаетси в CompaneTo по значениго, 
и никакои упаковки не требуетсл. 

□ Приведение типа к IComparable. Когда ввшолннетсл приведение типа pl к пере- 
меннои интерфеисного типа (с), упаковка pl необходима, так как интерфеисБ1 
по определениго имегот ссбшочнбш тип. Позтому вБшолннетсл упаковка pl, 
а указателв на зтот упакованнБп! обвект сохраннетсл в переменнои с. Следугогции 
вбгоов GetType подтверждает, что с деиствителвно ссншаетсл на упакованнБп! 
обвект Point в куче. 

□ Второи вбгоов CompareTo. При втором ввгоове CompaneTo упаковка pl не про- 

изводитсн, потому что Point реализует метод CompaneTo, и компиллтор может 
ввгоБшатБ его напрлмуго. Заметнте, что в CompaneTo передаетсл переменнан с 
интерфеиса ICompanable, позтому компилнтор вБтзвшает перегруженнуго версиго 
CompaneTo, котораи принимает параметр типа Object. Зто означает, что переда- 
ваемвш параметр должен ивлнтбси указателем, ссБшагогцимси на обвект в куче. 
К счаствго, с уже ссБшаетсл на упакованнБш обвект Point, по зтои причине 
адрес памлти из с может передаватБСл в CompaneTo и никакои дополнителвнои 
упаковки не требуетсл. 

□ Третии вбгоов CompareTo. При третвем ввгоове CompaneTo переменнал с уже 
ссвшаетсл на упаковашшш обвект Point в куче. Посколвку переменнан с сама 
по себе имеет интерфеиснБш тип ICompanable, можно внгоБшатБ толбко метод 
CompaneTo интерфеиса, а ему требуетсл параметр Ob ject. Зто означает, что пере- 
даваемБш аргумент должен 6 бгтб указателем, ссБшагогцимсл на обвект в куче. 
Позтому вБшолннетсл упаковка р2 и указателв на зтот упакованнБпг обвект 
передаетсл в CompaneTo. 
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□ Приведение типа к Point. Когда вБшолнлетсл приведение с к типу Point, обв- 
ект в куче, на которни указшвает с, распаковшваетсл, и его полл копируготсл из 
кучи в Р2, зкземплнр типа Point, находишиисн в стеке. 

Понимак), что всн зта информации о ссмлочнмх и значиммх типах, упаковке 
и распаковке поначалу вмглчдит устрашакчце. И все же лгобои разработчик, стре- 
мнгциисн к долгосрочному успеху на ниве .NET Framework, должен хорошо усвоитБ 
зти поннтгш — толбко так можно научитБСн бмстро и легко создаватг> зффективнБге 
приложенин. 


Изменение полеи в упакованнмх значиммх 
типах посредством интерфеисов (и почему 
зтого лучше не делатБ) 

Посмотрим, насколБКО хорошо вбг усвоили тему значимБгх типов, упаковки гг распа- 
ковки. Взглнните на следугогции пример: можете ли вбг сказатБ, что будет вБгведено 
на консолб в следугогцем случае. 

using System; 

// Point - значимми тип. 
internal struct Point { 
private Int32 m_x, m_y; 

public Point(Int32 х, Int32 у) { 
m_x = х; 
m_y = у; 

} 

public void Change(Int32 х, Int32 у) { 
m_x = х; m_y = у; 

> 

public override String ToString() { 

return String.Format("({0}, {1})", m_x.ToString(), m_y.ToString()); 

} 

} 

public sealed class Program { 
public static void Main() { 

Point p = new Point(l, 1); 

Console.WriteLine(p); 

p.Change(2, 2); 

Console.WriteLine(p); 


Object o = p; 


продолжение & 
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Console . WriteLine(o) ; 

((Point) o).Change(3, 3); 

Console.WriteLine(o); 

} 

} 

Bce просто: Main создает в стеке зкземплнр р типа Point и устанавливает его полн 
m_x и m_y равнмми 1. Затем р пакуетсл до первого обрагценгш к методу WriteLine, 
которми вмзмвает ToStning длн упакованного типа Point, в резулвгате вмводитсл, 
как и ожидалосв, (1,1). Затем р примениетсл длл вмзова метода Change, которми 
измениет значенин полеи m_x и m_y обЂекта р в стеке на 2. При втором обрашении 
к WniteLine, как и предполагалосБ, вмводитсл (2, 2). 

Далее р упаковмваетсл в третии раз — о ссмлаетсл на упакованнми обЂект типа 
Point. При третЂем обрагцении к WniteLine снова вмводитсл (2, 2), что опитђ 
вполне ожидаемо. И наконец, и обратаккт. к методу Change дли измененгш полеи 
в упакованном обвекте типа Point. Между тем Ob ject (тип переменнои о) ничего 
не «знает» о методе Change, так что сначала нужно привести о к Point. При таком 
приведении типа о распаковмваетсл, и полл упакованного обвекта типа Point 
копируготсл во временнми обвект типа Point в стеке потока. Поли m_x и m_y зтого 
временного обвекта устанавливаготсл равнмми 3, но зто обрагцение к Change не 
влгшет на упакованнми обвект Point. При обрагцении к WniteLine снова вмводитсн 
(2, 2). Длн многих разработчиков зто оказмваетсл неожиданнмм. 

Некоторме лзмки, например C++/CLI, позволнгот изменнтЂ полн в упакованном 
значимом типе, но толђко не С#. Однако и C# можно обманутЂ, применив интер- 
феис. Вот модифицированнал версин предмдугцего кода: 

using System; 

// Интерфеис, определнкиции метод Change 
intennal intenface IChangeBoxedPoint { 
void Change(Int32 х, Int32 у); 

} 

// Point - значимми тип 

intennal struct Point : IChangeBoxedPoint { 
private Int32 m_x, m_y; 

public Point(Int32 х, Int32 у) { 
m_x = х; 

т_У = у; 

} 

public void Change(Int32 х, Int32 у) { 
m_x = х; m_y = у; 

} 

public overnide String ToString() { 

return String.Format("({0}, {!})", m_x.To_String(), m_y.ToString()); 
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} 

} 

public sealed class Program { 
public static void Main() { 

Point p = new Point(lj 1); 

Console.WriteLine(p); 

p.Change(2, 2); 

Console.WriteLine(p); 

Object o = p; 

Console.WriteLine(o); 

((Point) o).Change(3, 3); 

Console.WriteLine(o); 

// p упаковнваетсп, упакованнни обвект изменнетсн и освобождаетсн 
( (IChangeBoxedPoint) p).Change(4, 4); 

Console.WriteLine(p); 

// Упакованнни обвект изменнетсв и внводитсв 
( (IChangeBoxedPoint) o).Change(5, 5); 

Console.WriteLine(o); 

} 

} 


Зтот код практически совпадает с предмдутцим. Основное отличие заклгочаетсл 
в том, что метод Change определнетсл интерфеисом IChangeBoxedPoint и теперБ тип 
Point реализует зтот интерфеис. Внутри Main первме четмре вмзова WriteLine те 
же самме и вмводлт те же резулвгатм (что и следовало ожидатћ). Однако в конец 
Main и добавил пару примеров. 

В первом примере р — неупакованнБш обвект типа Point — приводитсл к типу 
IChangeBoxedPoint. Такое приведение типа вБШБшает упаковку р. Метод Change 
вБ13Бшаетсн длн упакованного значенин, и его полн m_x и m_y становнтсн равнвши 4, 
но при возврате из Change упакованнвш обвект немедленно становитсн доступнвш 
длн уборки мусора. Так что при пнтом обрагцении к WniteLine на зкран вбшодитсл 
(2, 2), что дл 'А многих неожиданно. 

В последнем примере упакованнБш тип Point, на которпш ссБшаетсл о, при- 
водитсл к типу IChangeBoxedPoint. Упаковка здесв не производитсл, посколвку 
тип о уже упакован. Затем ввввшаетсл метод Change, которБш изменнет полн m_x 
и m_y упакованного типа Point. Интерфеиснвш метод Change позволил мне изме- 
нитб полн упакованного обвекта типа Point! Теперв при обрагцении к WniteLine 
вбшодитсл ( 5 , 5 ). И привел зти примерБц что6б1 продемонстрироватБ, как метод 
интерфеиса может изменитк поли в упакованном значимом типе. В C# сделатв зто 
без интерфеисов нелвзи. 
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ВНИМАНИЕ 

Ранее в зтои главе л отмечал, что значимме Tnnbi должнб! 6biTb неизменлемими, то 
ecTb в значими 1 хтипах нелизл определптв членн, которне изменлк)ткакие-либо полл 
зкземпллра. Фактически л рекомендовал, чтобм такие полл взначиммхтипах помеча- 
лиси спецификатором readonly, 4to6w компиллтор сообш,ил об ошибке, если вм вдруг 
случаино напишите метод, пи 1 та 101 диисл модифицироватвтакое поле. Предв 1 душ,ии 
пример как нелизл лучше иллкзстрирует зто. Показанное в примере неожиданное 
поведение программм пропвллетсл при попмтке вмзваљ методв!, изменлк)ш,ие полл 
зкземпллра значимого типа. Если после созданил значимого типа не Bbi3biBaTb мето- 
дм, изменлкидие его состочние, не возникнет недоразумении при копировании полл 
в процессе упаковки и распаковки. Если значимми тип неизменлемв 1 и, резулитатом 
будет простое многократное копирование одного и того же состолнил, позтому не 
возникнет непониманил наблкздаемого поведенил. 

Некоторме глави зтои книги л показал разработчикам. Познакомившисв с примерами 
программ (например, из зтого раздела), они сказали, что решили держаљсл подали- 
ше от значимв 1 х типов. Должен сказати, что зти незначителннме нкзансм значиммх 
типов стоили мне многодневнои отладки, позтому п и onncbiBaio их в зтои книге. 
Hafleiocb, bw не забудете об зтих нкзансах, тогда они не застигнут вас врасплох. Не 
боитеси значиммхтипов — они полезнм и занимакзт свокз нишу. Просто не забв 1 ваите, 
что ccbmo^Hbie и значимме типш ведут себч по-разному в зависимости от того, как 
применчкзтсл. Возимите предв 1 ду|дии код и обЂлвите Point как class, а не struct — 
увидите, что все получитсп. И наконец, радостнал новости заклк)чаетсл в том, что 
3Ha4HMbieTnnbi, содержашиесл вбиблиотеке FCL— Byte, Int32, Ulnt32, Int64, Ulnt64, 
Single, Double, Decimal, Biglnteger, Complex и все перечислимме типн, — лвллкзтсл 
неизменлемв 1 ми и не преподнослт никаких скзрпризов. 


Равенство и тождество обвектов 

Часто разработчикам приходитсл создаватБ код сравненин обвектов. В частности, зто 
необходимо, когда обвектм размегцаготсн в коллекцинх и требуетси писатБ код длн 
сортировки, поиска и сравненин отделБнмх злементов в коллекции. В зтом разделе 
рассказмваетсл о равенстве и тождестве обвектов, а также о том, как определитБ 
тип, KOTopbiri правилБно реализует равенство обЂектов. 

У типа System.Object естБ виртуалБНБП! метод Equals, которБш возврагцает 
true дли двух «равнБ 1 х» обЂектов. Вот как вмглндит реализацин метода Equals 
длн Object: 

public class Object { 

public virtual Boolean Equals(Object obj) { 

// Если обе сснлки указмватт на один и тот же обЂект, 

// значит, зти обЂектм равнн 
if (this == obj) return true; 

// Предполагаем, что обЂектн не равнн 
return false; 

} 

} 
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На первми взглнд зта реализации вмглндит вполне разумно: сравниваготсл две 
ссмлки, переданнме в аргументах this и obj, и если они указмвагот на один обвект, 
возврагцаетсн true, в противном случае возврагцаетсн false. Зто кажетсн логичнмм, 
так как Equals <<понимает», что обвект равен самому себе. Однако если аргументм 
ссмлаготсл на разнме обвектм, Equals сложнее определитБ, содержат ли обвектм 
одинаковме значенин, позтому возврагцаетсл f alse. Иначе говори, оказмваетсн, 
что стандартнач реализацин метода Equals типа Object реализует проверку на 
тождество, а не на равенство значении. 

Как видите, приведеннан здесв стандартнал реализации никуда не годитсл. 
Проблема немедленно становитсл очевиднои, стоит вам подуматг> об иерархилх 
наследовании классов и правилБном переопределении Equals. Вот как должна 
деиствоватБ правилБнан реализацгга метода Equals: 

1 . Если аргумент obj равен null, вернутв f alse, так как нсно, что текугции обвект, 
указаннБги в this, не равен null при ввгзове нестатического метода Equals. 

2 . Если аргументвг obj и this ссБглаготсн на обвектБг одного типа, вернутв true. 
Зтот гнаг поможет повбгситб производителБностБ в случае сравненин обвектов 
с многочисленнБгми полими. 

3 . Если аргументБг ob ј и this ссБглаготсл на обвектБг разного типа, вернутв f alse. 
Понитно, что резулБтат сравненгга обвектов String и FileStream равен false. 

4 . СравнитБ все определеннвге в типе зкземшгарнвге полл обвектов obj и this. 
Если хотн 6бг одна пара полеи не равна, вернутв f alse. 

5 . ВБгзватБ метод Equals базового класса, чтобвг сравнитБ определеннБге в нем 
поли. Если метод Equals базового класса вернул false, тоже вернутв false, 
в противном случае вернутв true. 

УчитБгван зто, компанин Microsoft должна бвгла 6бг реализоватБ метод Equals 
типа Object примерно так: 

public class Object { 

public virtual Boolean Equals(Object obj) { 

// Сравниваемми обБект не может 6biTb равним null 
if (obj == null) return false; 

// OčbeKTbi разних типов не могут 6мтб равнм 
if (this.GetType() != obj .GetTypeQ) return false; 

// Если типи обБектов совпадагат, возврашаем true при условии, 

// что все их полв попарно равни. 

// Так как в System.Object не определенм полл, 

// следует считатв, что полл равни 
return true; 

} 

} 

Однако, посколБку в Microsoft метод Equals реализован иначе, правила соб- 
ственнои реализации Equals намного сложнее, чем кажетсч. Если вагн тип пере- 
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определнет Equals, переопределеннан версип метода должна вмзмватБ реализацшо 
Equals базового класса, если толбко не планируетсн вмзмватБ реализацшо в типе 
Object. Зто означает егце и то, что посколБку тип может переопределнтБ метод 
Equals типа Object, зтот метод болБше не может исполћзоватБСн дли проверки на 
тождественностБ. Длл исправленгш ситуации в Object предусмотрен статическии 
метод ReferenceEquals со следугогцим прототипом: 

public class Object { 

public static Boolean ReferenceEquals(Object objA, Object objB) { 
return (objA == objB); 

} 

} 

Длн проверки на тождественноств нужно всегда ввгоБшатБ ReferenceEquals (то 
естБ проверитБ на предмет того, относлтси ли две ссбшки к одному обвекту). Не 
нужно исполБЗОватБ оператор == измка C# (если толбко перед зтим оба операнда 
не приводлтсн к типу Ob ј ect), так как тип одного из операндов может перегружатв 
зтот оператор, в резулвтате чего его семантика перестает соответствоватБ поннтиго 
«тождественностБ». 

Как видите, в области равенства и тождественности в ,NET Framework дела 
обстолт доволбно сложно. Кстати, в System.ValueType (базовом классевсехзначи- 
MBix типов) метод Equals типа Object переопределен и корректно реализован длн 
проверки на равенство (но не тождественноств). Внутреннн реализацгш переопреде- 
ленного метода работает по следугогцеи схеме: 

1 . Если аргумент obj равен null, вернутв f alse. 

2. Если аргументБг obj и this ссБглаготсн на обвектБг разного типа, вернутБ 
false. 

3 . Длн каждого зкземплнрного полн, определенного типом, сравнитБ значение из 
обп>окта obj со значением из обвекта this вбгзовом метода Equals поли. Если 
хотн 6бг одна пара полеи не равна, вернутв f alse. 

4 . ВернутБ true. Метод Equals типа ValueType не вБгзБшает одноименнБпг метод 
типа Object. 

Длн вБшолненгш шага 3 в методе Equals типа ValueType исполвзуетсн отражение 
(см. главу 23). Так как отражение в CLR работает медленно, при создании собствен- 
ного значимого типа нужно переопределитв Equals и создатБ свого реализациго, 
чтобвг ПОВБ1СИТБ производителБностБ сравненгш значении на предмет равенства 
зкземплнров созданного типа. И, конечно же, не стоит вБгзвшатБ из зтои реализации 
метод Equals базового класса. 

Определил собственнвш тип и принив решение переопределитв Equals, обе- 
спечБте поддержку четнгрех характеристик, присугцих равенству: 

□ РефлексивностБ: x.Equals(x) должно возврагцатв true. 

□ Симметричностћ: x.Equals(y) и y.Equals(x) должнбг возврагцатБ одно и то 


же значение. 
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□ Транзитивностћ: если х. Equals (у) нозврашаст' true н у. Equals ( z ) возврашает 
true, то х. Equals (z) также должно возвратцатБ true. 

□ Постоннство: если в двух сравниваеммх значенинх не произошло изменении, 
резулшат сравнентш тоже не должен изменитБСч. 

Отступление от зтих правил при создании собственнои реализации Equals 
грозит непредсказуемБш поведением приложенгш. 

При переопределении метода Equals может потребоватБСн вбшолнитб несколБКО 
дополнителБНБ1х операции. 

□ Реализоватћ в типе метод Equals интерфеиса System.IEquatable<T>. Зтот 
обобгценнБП! интерфеис позволиет определитв безопаснБп! в отношении типов 
метод Equals. Обвшно Equals реализугот так, что, принимаи параметр типа 
Object, код метода ввгоБшает безопаснБш в отношении типов метод Equals. 

□ Перегрузитћ методБ1 операторов == и !=. Обвшно код реализации зтих опера- 
торнБ1х методов ввгоБшает безопаснБпг в отношении типов метод Equals. 

Если предполагаетсн сравниватв зкземплнрБ1 собственного типа длн целеи сортн- 
ровки, рекомендуетсл также реализоватв метод CompareTo типа System . Icomparable 
и безопаснБп! в отношении типов метод CompareTo типа System . IComparable<T>. 
Реализовав зти методБ1, можно реализоватБ метод Equals так, что 6 б 1 он вБГОБшал 
CompareTo типа System.IComparable<T> и возврашал true, если CompareTo воз- 
вратит 0 . После реализации методов Compa reT о также часто требуетси перегрузитв 
методБ1 различнБ1х операторов сравненгш (<, <=, >, >=) и реализоватв код зтих 
методов так, чтобв! он вБГОБшал безопаснБпг в отношении типов метод CompareTo. 


Хеш-кодн обг»ектов 

Разработчики FCL решили, что 6б1ло 6б1 чрезвБшаино полезно иметБ возмож- 
ностб добавленгш в хеш-таблицвг лго6бгх зкземплцров лгобвгх типов. С зтои целвго 
в System .Object вклгочен виртуалвнБш метод GetHashCode, позволнгогции вбшис- 
литб длл лгобого обвекта целочисленнБпг (Int 32 ) хеш-код. 

Если вб1 определлете тип и переопределлете метод Equals, вбг должнбг пере- 
определитБ и метод GetHashCode. Если при определении типа переопределитБ 
толбко один из зтих методов, компиллтор C# вБгдаст предупреждение. Например, 
при компилиции представленного далее кода понвитсл предупреждение: warning 
CS 0659 : ’Program' overrides Object. Equals(Object o) but does not override 
Object.GetHashCode()('Program' переопределнет Object.Equals(Object o), но 
не переопределлет Object.GetHashCode()). 

public sealed class Program { 

public override Boolean Equals(Object obj) { ... } 

} 
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Причина, по которои в типе должнм 6мтб определенв1 оба метода — Equals 
и GetHashCode, — состоит в том, что реализацил типов System . Collectlons . 
Hashtable, System.Collections .Generic .Dictionary илгобмх другихколлекции 
требует, чтобм два равнмх обвекта имели одинаковме значенин хеш-кодов. По- 
зтому, переопределлл Equals, нужно переопределитБ GetHashCode и обеспечитБ 
соответствие алгоритма, применпемого длл ВБгаисленил равенства, алгоритму, 
исполБзуемому дли ВБ1численил хеш-кода обвекта. 

По сути, когда bki добавлиете пару «клгоч-значение» в коллекциго, перввш 
вБшислиетсл хеш-код клгоча. Он указктает, в каком «сегменте» будет хранитвсн 
пара «клгоч-значение». Когда коллекции требуетсл наити некии клгоч, она вбн 
числлет длл него хеш-код. Хеш-код определлет «сегмент» поиска имегогцегосл 
в таблице клгоча, равного заданному. Применение зтого алгоритма храненгш и 
поиска клгочеи означает, что если bbi измените храннгцииси в коллекции клгоч 
обвекта, коллекцил болвше не сможет наити зтот обвект. Если bki намеренБ1 
изменитБ клгоч обвекта в хеш-таблице, то сначала удалите имегогцугосл пару 
«клгоч-значение», модифицируите клгоч, а затем добаввте в хеш-таблицу новуго 
пару «клгоч-значение». 

В определении метода GetHashCode нет oco6bix хитростеи. Однако длл некоторБ1х 
типов даннБгх и их распределенгш в памлти бвшает непросто подобратв алгоритм 
хешировангш, которвш вввдавал 6bi хорошо распределеннБпг диапазон значении. 
Вот простои алгоритм, неплохо подходнгции длн обвектов Point: 

internal sealed class Point { 
private readonly Int32 m_x, m_y; 
public override Int32 GetHashCode() { 

return m_x л m_y; // Исклгачакпцее ИЛИ длл m_x и m_y 

} 


Bbionpaa алгоритм вБгчисленгш хеш-кодов длл зкземплнров своего типа, ста- 

раитесв следоватБ определеннБш правилам: 

□ Исполвзуите алгоритм, которБпг дает случаиное распределение, noisi.iiiiaioiucc 
производителБностБ хеш-таблицБ1. 

□ Алгоритм может вБ13БшатБ метод GetHashCode базового типа и исполвзоватБ 
возврагцаемое им значение, однако в обгцем случае лучше отказатвсн от iii.i3.oiia 
встроенного метода GetHashCode длн типа Object или ValueType, так как зти реа- 
лизации обладагот низкои производителБноствго алгоритмов хешировангш. 

□ В алгоритме должно исполБЗОватБСн как минимум одно зкземплнрное поле. 

□ Поли, исполБзуемБШ в алгоритме, в идеале не должнб1 изменнтБСн, то естБ они 
должнб1 инициализироватБСц при создании обвекта и сохраннтк значение в те- 
чение всеи его жизни. 

□ Алгоритм должен 6bitb максималБно бнгстрБш. 
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□ ОбЂектм с одинаковмм значением должнм возвратцатБ одинаковме кодм. На- 
пример, два обвекта Stning, содержатцие одинаковми текст, должнм возвравдатБ 
одно значение хеш-кода. 

Реа. : i п з; ш п и G е t Н а s h С о d е в System.Object ничего <<незнает» о производнмх типах 
и их полнх. Позтому зтот метод возврагцает число, однозначно идентифицирукдцее 
оођскт в пределах домена приложении; при зтом гарантируетси, что зто число не 
изменитсн на протнжении Bceii жизни обвекта. 

ВНИМАНИЕ 

Если bw взплисв за собственнунз реализацик) хеш-таблиц или пишете код, в котором 
будет Bbi 3 biBaTbca метод GetHashCode, никогда не сохранлите значенин хеш-кодов. 
Они подверженн изменениам в силу своеи природвк Например, при переходе 
к следукдцеи версии типа алгоритм вв1численил хеш-кода обвекта может просто 
изменитвсп. 

R знас компаник), которал проигнорировала зто предупреждение. Посетители ее 
веб-саита создавали новме учетнне записи, Bbi6npaa имп пол^зователл и naponb. 
Строка (Stning) паролл передаваласљ методу GetHashCode, а полученнвш хеш- 
код сохранллсл в базе данннх. В далвнеишем при входе на веб-саит посетители 
указв1вали свои пароли, которми снова o6pa6aTbieaacn методом GetHashCode, 
и полученнвш хеш-код сравнивалсл с сохраненни1м в базе даннмх. При совпадении 
полизователк) предоставлплсл доступ. К несчасљк), после обновленин версии CLR 
метод GetHashCode типа Stning изменилсл и стал возвраш,атв другои хеш-код. 
Резулитат оказалсп плачевнмм — все полизователи потерлли доступ к веб-саиту! 


ПримитивнБш тип даннмх dynamic 

Измк C# обеспечивает безопасностБ типов даннмх. Зто означает, что все вмра- 
жепим разрешаготси в зкземплнр типа и компилнтор генерирует толбко тот код, 
которми стараетси представитБ операции, правомернме длл данного типа даннмх. 
Преимугцество от исполБЗОванин нзмка, обеспечивагогцего безопасностБ типов дан- 
нмх, заклгочаетсн в том, что егце на зтапе компилиции обнаруживаетсл множество 
ошибок программировангш, что помогает программисту скорректироватБ код перед 
его вмполнением. К тому же при помогци подобнмх нзмков программированин 
можно получатБ более 6biCTpbie приложенгш, потому что они разрешагот болБше 
допугцении егце на зтапе компилиции и затем переводлт зти допугценин в изб 1 К IL 
или метаданнБ 1 е. 

Однако возможнб 1 неприлтнБге ситуации, возникагогцие из-за того, что программа 
должна вбшолннтбсн на основе информации, недоступнои до ее вБшолнешш. Если 
вб1 исполБзуете нзбши программировангш, обеспечивагогцие безопасностБ даннБ1х 
(например, С#) дли взаимодеиствии с зтои информациеи, синтаксис становитси 
громоздким, особенно в случае, если вб! работаете с множеством строк, в резулБ- 
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тате производителБностБ приложенил падает. Если bhi пишете приложение на 
«чистом» нзБше С#, непринтнап ситуацин может подстерегатн вас толбко во времн 
работБ1 с информациеи, определиемои на зтапе вБшолненип, когда bki исполБзуете 
отраженин (см. главу 23). Однако многие разработчики исполвзугот также C# длл 
свизи с компонентами, не реализованнвши на С#. Некоторнге из зтих компонентов 
могут 6 б 1 тб написанБ 1 на динамических пзБшах, например Python или Ruby, или 
6 б 1 тб СОМ-обвектами, которкге поддерживагот интерфеис IDispatch (возможно, 
реализованнБП! на С или С++), или обвектами модели DOM (Document Object 
Model), реализованнБши при помопди разнБ 1 х нзбшов и технологии. Взаимодеиствие 
с DOM -обвектами особенно полезно длн построенин Silverlight -приложении. 

Длл того что 6 б 1 облегчитБ разработку при помогци отражении или коммуни- 
кации с другими компонентами, компилитор C# предлагает помечатн типб 1 как 
динамические (dynamic). Bki также можете запискшатБ резулБтатБ1 вБшисленгш вбп 
ражении в переменнуго и пометитв ее тип как динамическии. Затем динамическое 
вБфажение (переменнал) может 6 бгтб исполБЗОвано длл вбгзовов членов класса, 
например поли, своиства/индексатора, метода, делегата, или унарнвгх/бинарнБгх 
операторов. Когда ваш код вБгзвшает член класса при помогци динамического вкгра- 
женгш (переменнои), компилнтор создает специалБНБпг IL -код, которБпг описБшает 
желаемуго операциго. Зтот код назБшаетсл полезноп нагрузкоп (payload). Во времн 
вБшолненгш программБг он определлет сугцествугогцуго операциго длн вБшолненгш 
на основе деиствителвного типа обвекта, на которкш ссБшаетсл динамическое вбг- 
ражение (переменнан). 

Следугогции код поисннет, о чем идет речк: 

internal static class DynamicDemo { 

public static void Main() { 
dynamic value; 

for (Int32 demo = 0; demo < 2; demo++) { 

value = (demo == 0) ? (dynamic) 5 : (dynamic) "A"; 
value = value + value; 

M(value); 

} 

} 

private static void M(Int32 n) { Console.WriteLine("M(Int32): " + n); } 

private static void M(String s) { Console.WriteLine("M(String): " + s); } 

} 

После вБшолненгш метода Main получаетсл следугогции резулБтат: 

M(Int32) : 10 
M(String) : АА 

Длн того что6бг поннтб, что здесБ происходит, обратимсн к оператору +. У зтого 
оператора имеготсп операндкг типа с пометкои dynamic. По зтои причине компи- 
литор C# генерирует код полезнои нагрузки, которкш провернет деиствителвнБпг 
тип переменнои value во времи ввшолненгш и определлет, что должен делатн 
оператор +. 
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Во времн первого вмзова оператора + значение его аргумента равно 5 (тип Int32), 
позтому резулБтат равен 10 (тоже тип Int32). РезулБтат присваиваетсн переменнои 
value. Затем ввиБшаетсн метод М, которому передаетсн value. Дли вБ130ва метода М 
компилитор создает код полезнои нагрузки, которвш на зтапе вБшолненгш будет 
проверитБ деиствителБНБпг тип значенгш переменнои, переданнои методу М. Когда 
value содержит тип Int32, вБИБшаетсн перегрузка метода М, получагогцан параметр 
Int32. 

Во времн второго ввгзова + значение его аргумента равно А (тип String), а ре- 
зулвтат представлнет собои строку АА (резулвтат конкатенацгш А с собои). Затем 
снова вБгзБгваетсл метод М, которому передаетсл value. На зтот раз код полезнои 
нагрузки определлет, что деиствителБНБш тип, переданнБпг в М, нвлнетсл строковвгм, 
и ББгзБгвает перегруженнуго версиго М со строковвгм параметром. 

Когда тип полн, параметр метода, возврагцаемБги тггп метода ггли локалБнал 
переменнан снабжаготсл пометкои dynamic, компиллтор конвертирует зтот тггп 
в тип System .Ob ject гг примениет зкземплнр System . Runtime . CompilerServices . 
DynamicAttribute к полго, параметру гглгг возврагцаемому типу в метаданнвгх. Еслгг 
локалБнан переменнап определена как динамггческан, то тггп переменнои также 
будет типом Ob ject, но атрибут DynamicAttribute непргшеним к локалкнБгм пере- 
меннБгм из-за того, что онгг исполБзуготсл толбко внутри метода. Из-за того, что 
тггпбг dynamic гг Ob ject одинаковБг, вбг не сможете создаватБ методБг с сигнатурами, 
отличагогцимисл толбко типамгг dynamic гг Object. 

Тгггг dynamic можно исполБЗОватк длл определенин аргументов тггпов обоб- 
гценнвгх классов (ссбглочнбги тип), структур (значггмБш тип), интерфеисов, деле- 
гатов илгг методов. Когда вбг зто делаете, компиллтор конвертирует тип dynamic 
в Object гг применнет DynamicAttribute к различнвгм частлм метаданнБгх, где зто 
необходимо. Обратите внимание, что обобгценнБш код, которкги вбг исполБзуете, 
уже скомпилирован в соответствгггг с типом Object, гг дггнамическан отправка не 
осугцествлнетсл, посколвку компилитор не проггзводит код полезнои нагрузки 
в обобгценном коде. 

Лгобое вБгражение может 6бгтб пвно прггведено к dynamic, посколвку все вбг- 
раженин дагот в резулвтате тип, проггзводнБги от Object 1 . В обгцем случае компгг- 
литор не позволит вам написатв код с ненвнБгм прггведенггем вБграженгш от тггпа 
Ob ј ect к другому типу, вбг должнбг исполБЗОватБ пвное прггведенгге типов. Однако 
компгглитор разрешит вбгполнитб прггведенгге типа dynamic к другому типу с ггс- 
полБЗОванием сггнтаксггса ненвного приведенин. 

Object ol = 123; // ОК: НеАвное приведение Int32 к Object (упаковка) 

Int32 nl = ol; // Ошибка: Нет ненвного приведенил Object к Int32 

Int32 n2 = (Int32) ol; // ОК: Лвное приведение Object к Int32 (распаковка) 

dynamic dl = 123; // ОК: Неввное приведение Int32 к dynamic (упаковка) 

Int32 n3 = d; // ОК: Неввное приведение dynamic к Int32 (распаковка) 


i 


И как обмчно, значимБги тип будет упакован. 
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Пока компиллтор позволиет пренебрегатБ нвнмм приведением динамического 
типа к другому типу даннмх, среда CLR на зтапе вмполненин провернет правилБ- 
ностб приведенгш с целБК) обеспеченгш безопасности типов. Если тип обвекта не- 
совместим с приведением, CLR вмдает исклгочение InvalidCastException. 
Обратите внимание на следугогции код: 

dynamic d = 123; 

var result = M(d); // 'var result' - то жв, что 'dynamic result' 

ЗдесБ компилитор позволлет коду компилироватБСи, потому что на зтапе ком- 
пиллции он не знает, какои из методов М будет вмзван. Следователћно, он также не 
знает, какои тип будет возврагцен методом М. Компиллтор предполагает, что пере- 
меннал result имеет динамическии тип. Вм можете убедитћсн в зтом, когданаведете 
указателБ ммши на переменнуго var в редакторе Visual Studio — во всплмвагогцем 
IntelliSense -окне вм увидите следугогцее. 

dynamic: Represents an object whose operations will be resolved at runtime. 

Если метод M, вмзваннми на зтапе вмполненгш, возврагцает void, вмдаетсл ис- 
клгочение Microsoft . CSharp . RuntimeBinder . RuntimeBinderException. 

ВНИМАНИЕ 

He путаите типб 1 dynamic и var. ОбЂлвление локалЂнои переменнои как var лвллетсл 
синтаксическим указанием компиллтору подставллтЂ специалЂНЂ1е даннЂ1е из со- 
ответству 1 ош,его внраженич. Клкзчевое слово var может исполБЗОватмш толђко длл 
обвлвленил локалБНЂ1х переменнБ1х внутри метода, тогда как клкзчевое слово dynamic 
можетуказЂ 1 ватЂсас локалБнмми переменннми, поллми иаргументами. Bbi не можете 
привести внражение ктипу var, но вм можете привести его ктипу dynamic. Bbi должнм 
нвно инициализироватв переменнукз, обЂчвленнукз как var, тогда как переменнукз, 
обЂнвленну 10 как dynamic, инициализировати нелЂЗл. Болвше подробно о типе var 
рассказмваетсл в главе 9. 


При преобразовании типа dynamic в другои статическии тип резулетатом будет, 
очевидно, тоже статическии тип. Аналогичнмм образом при создании типа с пере- 
дачеи конструктору одного и более аргументов dynamic резулвгатом будет обвект 
того типа, KOTopbiri Bbi создаете: 

dynamic d = 123; 

var х = (Int32) d; // Конвертацил: ’var х’ одинаково c 'Int32 х' 

var dt = new DateTime(d); // Создание: ’var dt' одинаково c 'DateTime dt’ 

Если вБфажение dynamic задаетси как коллекцгш в инструкции foreach или 
как ресурс в директиве using, то компшштор генерирует код, которБш по 1 њпаст- 
сн привести вБфажение к необобгценному интерфеису System.IEnumerable или 
интерфеису System . IDisposable соответственно. Если приведение типов Bbi- 
полниетсл успешно, то вБфажение исполБзуетси, а код вБшолннетси нормалБно. 
В противном случае будет вБвдано исклгочение Mic rosof t . CSharp. RuntimeBinder. 
RuntimeBinderException. 
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ВНИМАНИЕ 

Внражение dynamic реалино имееттотжетип, что и System.Object. Компиллтор при- 
нимаетоперации с вмражением какдопустимие и не генерирует ни предупреждении, 
ни ошибок. Однако исклкзченил могутбмтв вмданм на етапе вмполненил программм, 
если программа попмтаетсл вмполнитв недопустимукз операцикз. К тому же Visual 
Studio не предоставллет какои-либо lntelliSense -поддержки длл написанил кода 
с динамическими вмраженилми. Bbi не можете определити метод расширенил длл 
dynamic (об зтом рассказмваетсл в главе 8), хотл можете его определитв дпл Object. 
И Bbi можете исполБЗОватБ ллмбда-вмражение или анонимнми метод (они оба обсуж- 
дакзтсл в главе 17) в качестве аргумента при вмзове динамического метода, потому 
что компиллтор не может BbNnannTb фактически исполБзуемие Tnnbi. 


Рассмотрим пример кода на C# с исполћзованием СОМ-обвекта IDispatch длн 
созданин книги Microsoft Office Excel и размешентга строки в ичеике Al. 

using Microsoft.Office.Interop.Excel; 

public static void Main() { 

Application excel = new Application(); 
excel.Visible = true; 
excel.Workbooks.Add(Type.Missing); 

((Range)excel.Cells[1, l]).Value = "Text in cell Al"; 

// Помецаем ату строку в лчеику Al. 

} 


Безтипа dynamic значение, возврашаемое excel .Cells[l, 1], имеет тип Object, 
которми должен 6мтб приведен к типу Range перед обрагцением к его своиству 
Value. Однако во времи генерации вмполнпемои «обертки» дли СОМ-обвекта 
лкзбое исполБЗОвание типа VARIANT в СОМ-методе будет преобразовано в dynamic. 
СледователБно, посколбку вмражение excel . Cells [1, 1 ] относитсн к типу dynamic, 
вам не обнзателБно нвно приводитћ его к типу Range дли обрагцешга к своиству 
Value. Преобразование к dynamic значителћно упрогцает код, взаимодеиствукзгции 
с СОМ-обЂектами. Пример более простого кода: 
using Microsoft.Office.Interop.Excel; 

public static void Main() { 

Application excel = new Application(); 
excel.Visible = true; 
excel.Workbooks.Add(Type.Missing); 
excel.Cells[l, l].Value = "Text in cell Al"; 

// Помецаем зту строку в лчеику А1 

} 


Следукзгции фрагмент показмвает, как исполћзоватБ отражение длл вмзова ме- 
тода (Contains) с аргументом типа Stning ("ff ") дллстроки ("leff пеу Richten") 
и поместитБ резулБтат с типом Int32 в локалБнуго переменнуго nesult. 

Object target = "leffrey Richter"; 

Object arg = "ff"; 
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// Находим метод, которми подходит по типам аргументов 
Туре[] argTypes = newType[] { arg.GetType() }; 

Methodlnfo method = target.GetType().GetMethodC’Contains", argTypes); 

// BbBbiBaeM метод c желаеммм аргументом 
Object[] arguments = newObject[] { arg }; 

Boolean result = Convert.ToBoolean(method.Invoke(target, arguments)); 

Если исполБЗОватБ тип C# dynamic, зтот код можно значителБно улучшитБ 
с точки зренин синтаксиса. 

dynamic target = "Deffrey Richter"; 
dynamic arg = "ff"; 

Boolean result = target.Contains(arg); 

Ранее л уже говорил о том, что компиллтор C# на зтапе вБшолненил про- 
граммБ1 генерирует код полезнои нагрузки, основБ1вапсБ на деиствителБНБ1Х 
типах обвекта. Зтот код полезнои нагрузки исполкзует класс, известнБш как 
компоновгцик (runtime binder). РазличнБ 1 е лзб1Ки программированил определл- 
к)т собственнБ 1 х компоновгциков, инкапсулируи в них правила лзвжа. Код длл 
компоновгцика C# находитсл в сборке Microsoft .CSharp.dll, позтому ссвшка на 
зту сборку должна вклгочатБСи в лгобои проект, исполвзугогции клгочевое слово 
dynamic. Зта сборка ссвшаетсц на фаил параметров по умолчаниго, CSC.rsp. Код 
из зтои сборки знает, что при применении оператора + примениетси к двум о6б- 
ектам типа Int32 следует генерироватБ код сложенил, а длл двух обвектов типа 
String — код конкатенации. 

Во времн вБшолненгш сборка Microsoft.CSharp.dll должна 6 бгтб загружена в до- 
мен приложении, что снизит производителвностБ приложенгш и повбгсит расход 
памнти. Кроме того, сборка Microsoft.SCharp.dll загружает библиотеки System.dll 
и System.Core.dll. Аесли вбг исполБзуете тип dynamic длл свнзи с СОМ-обвектами, 
загружаетсн и библиотека System.Dynamic.dll. И когда будет вБшолнен код полезнои 
нагрузки, генериругогции динамическии код во времл вБшолненгш, зтот код окажетсл 
в сборке, названнои анотшноп сборкоп динамических методов (Anonymously Hosted 
Dynamic Methods Assembly). Назначение зтого кода заклгочаетсл в повБгшении 
производителБности динамических ссбглок в ситуацинх, в которвгх конкретное 
место ввгзова (call site) ввгдает много вбгзовов с динамическими аргументами, со- 
ответствугогцих одному типу на зтапе ввшолненгш. 

Из-за всех издержек, свнзаннвгх с особенностнми встроеннБгх динамических вбг- 
числении в С#, вбг должнбг осознанно решитБ, что именно вбг желаете добитБСл от 
динамического кода: превосходнои производителвности приложенгш при загрузке 
всех зтих сборок или оптималвного расходовангш памлти. Если динамическии код 
исполБзуетсл толбко в паре мест вашего программного кода, разумнее придержи- 
ватвсн старого подхода: либо вБ13Б1ватБ методБг отраженгш (длл управлнемБгх обв- 
ектов), либо <<вру4нуго>> ПрИВОДИТБ ТИПБ1 (длн СОМ-обЂектов). 

Во времи вмполнениц компоновгцик C# разрешает динамические операцгш 
в соответствии с типом обвекта. Сначала компоновгцик провериет, реализуетсл 
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ли типом интерфеис IDynamicMetObjectProvider. И если интерфеис реализо- 
ван, вмзмваетсл метод GetMetaObject, которми возврашает тип, производнми 
от DynamicMetaObject. Зтот тип может обработатБ все привнзки членов, методов 
и операторов, свнзаннБ1е с обЂектом. Интерфеис IDynamicMetaObjectProvider 
и ocHOBHOii класс DynamicMetaObject определенБ1 в пространстве имен System. 
Dynamic и находлтси в сборке System.Core.dll. 

Динамические нзбгки, такие как Python и Ruby, исполБзугот типбг, производнБге 
от DynamicMetaObject, что позволиет взаимодеиствоватв с ними из других лзбг- 
ков (например, С#). Аналогичнвш образом компоновгцик C# при свнзи с СОМ- 
компонентами будет исполвзоватБ порожденнБги тип DynamicMetaObject, умегогции 
взаимодеиствоватБ с СОМ-компонентами. ПорожденнБш тип DynamicMetaObject 
определен в сборке System.Dynamic.dll. 

Если тип обвекта, исполБзуемБш в динамическом вБгражении, не реализует 
интерфеис IDynamicMetaObjectProvider, тогдакомпилнтор C# воспринимает его 
как обвгчнБпг обвект типа изкгка C# и все свнзаннвге с ним деиствин осугцествллет 
через отражение. 

Одно из ограниченгш динамических типов заклгочаетсн в том, что они могут 
исполБЗОватБСл толбко длл обрагценгш к членам зкземплнров, потому что дина- 
мическан переменнан должна ссвглатБСи на обвект. Однако в некоторвгх случалх 
бвгвает полезно динамически вБгзвшатБ статические методкг типа, определнемого 
во времн вБшолненин. Дли зтого л создал класс StaticMemberDynamicWrapper, 
производнБпг от класса Sy stem . Dynamic . DynamicOb ј ect, реализугогцего интерфеис 
IDynamicMetaObjectProvider. Во внутреннеи реализацгш зтого класса активно 
исполБзуетсл отражение (см. главу 23 ). Ниже приведен код моего класса Static- 
MemberDynamicWrapper. 

internal sealed class StaticMemberDynamicWrapper : DynamicObject { 

private readonly TypeInfo m_type; 

public StaticMemberDynamicWrapper(Type type) { m_type = type.GetTypeInfo(); } 

public override IEnumerable<String> GetDynamicMemberNames() { 
return m_type.DeclaredMembers.Select(mi => mi.Name); 

} 

public override Boolean TryGetMember(GetMemberBinder binder, out object result) 

{ 

result = null; 

var field = FindField(binder.Name); 

if (field != null) { result = field.GetValue(null); return true; } 
var prop = FindProperty(binder.Name, true); 

if (prop != null) { result = prop.GetValue(null, null); return true; } 
return false; 

} 

public override Boolean TrySetMember(SetMemberBinder binder, object value) { 
var field = FindField(binder.Name); 
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if (field != null) { field.SetValueCnullj value); return true; } 
var prop = FindProperty(binder.Name, false); 

if (prop != null) { prop.SetValue(null, value, null); return true; } 
return false; 

} 

public override Boolean TryInvokeMember(InvokeMemberBinder binder, Objectf] 
args, 

out Object result) { 

Methodlnfo method = FindMethod(binder.Name); 
if (method == null) { result = null; return false; } 
result = method.Invoke(null, args); 
return true; 

} 

private Methodlnfo FindMethod(String name, Type[] paramTypes) { 

return m_type.DeclaredMethods.FirstOrDefault(mi => mi.IsPublic && 
mi.IsStatic 

&& mi.Name == name 

&& ParametersMatch(mi.GetParameters(), paramTypes)); 

} 

private Boolean ParametersMatch(ParameterInfo[] parameters, Type[] 
paramTypes) { 

if (parameters.Length != paramTypes.Length) return false; 
for (Int32 i = 0; i < parameters.Length; i++) 

if (parameters[i].ParameterType != paramTypes[i]) return false; 
return true; 

} 

private Fieldlnfo FindField(String name) { 

return m_type.DeclaredFields.FirstOrDefault(fi => fi.IsPublic && fi.IsStatic 
&& fi.Name == name); 

} 

private PropertyInfo FindProperty(String name, Boolean get) { 
if (get) 

return m_type.DeclaredProperties.FirstOrDefault( 
pi => pi.Name == name && pi.GetMethod != null && 
pi.GetMethod.IsPublic && pi.GetMethod.IsStatic); 

return m_type.DeclaredProperties.FirstOrDefault( 
pi => pi.Name == name && pi.SetMethod != null && 
pi.SetMethod.IsPublic && pi.SetMethod.IsStatic); 

} 

} 

Чтобм вшзватБ статическии метод динамически, сконструируите зкземплир 
класса с передачеи Туре и сохраните ссбшку на него в динамическукз переменнуго. 
Затем вБ130вите нужнБ1и статическии метод с исполБЗОванием синтаксиса bbi- 
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зова зкземплнрного метода. Пример вмзова статического метода Concat(Stringj 
String) класса Stning: 

dynamic stringType = new StaticMemberDynamicWrapper(typeof(String)); 
var r = stringType.Concat("A", "B"); // Динамическии внзов статического 

// метода Concat класса String 
Console.WriteLine(r); // внводитсн "АВ" 



Глава 6. OcHOBHbie сведенил 
о членах и типах 


В главах 4 и 5 бмли рассмотренм типм и операции, применимме ко всем зкзем- 
плнрам лгобого типа. Кроме того, о6ђпснплосг>, почему все типм делитси на две 
категории — ссмлочнме и значимме. В зтои и последугогцих главах н показмваго, 
как проектироватБ типм с исполБЗОванием различнмх членов, которме можно 
определитБ в типах. В главах с 7 по 11 зти членв! рассматриваготси подробнее. 


Членн типа 

В типе можно определитв следугогцие членБг. 

□ Константа — идентификатор, определнгогции некуго постонннуго величину. Зти 
идентификаторБг о6бгчно исполБзугот, что6бг упроститБ чтение кода, а также 
длл удобства сопровожденгш и поддержки. Константвг всегда свизанвг с типом, 
а не с зкземплнром типа, а на логическом уровне константвг всегда нвлнготсн 
статическими членами. Подробнее о константах см. главу 7. 

□ Поле представлнет собои значение даннвгх, доступное толбко длл чтенин или 
длл чтенгш/записи. Поле может 6бгтб статическим — тогда оно нвлнетсл частвго 
состоингш типа. Поле может 6бгтб зкземплирнБгм (нестатическим) — тогда оно 
нвлиетси частБго состоингш конкретного обнекта. Л настоителБно рекомендуго 
ограничиватБ доступ к полнм, что6бг внешнии код не мог нарушитв состоиние 
типа или обнекта. Подробнее о полих см. главу 7. 

□ Конструктор зкземплнров — метод, служагции длн инициализацгш полеи зк- 
земплнра при его создании. Подробнее о конструкторах зкземплнров см. главу 8. 

□ Конструктор типа — метод, исполБзуемБш дли инициализации статических 
полеи типа. Подробнее о конструкторах типа см. главу 8. 

□ Метод представлнет собои функциго, вБшолшггогцуго операции, которнге из- 
меннгот или запрашивагот состонние типа (статическии метод) или обвекта 
(зкземплирнБпг метод). Методнг о6бшно осугцествлнгот чтение и запггсв полеи 
типов или обвектов. Подробнее о методах см. главу 8. 

□ Перегруженнми оператор определлет, что нужно проделатв с обЂектом при 
применении к нему конкретного оператора. Перегрузка операторов не входит 
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в обтцензБЖОвук) спецификациго CLS, посколБку не все лзнки программированин 
ее поддерживагот. Подробнее о перегруженннх операторах см. главу 8. 

□ Оператор преобразовании — метод, задагогции порндок нвного или неивного 
преобразованин обвекта из одного типа в другои. Оператори преобразовангш 
не входлт в спецификациго CLS по тои же причине, что и перегруженние опе- 
ратори. Подробнее об операторах преобразовангш см. главу 8. 

□ Своиство представлиет собои механизм, позволигогции применитв простои 
синтаксис (напоминагогции обрагцение к полим) длл установки или полученгш 
части логического состоннгш типа или обвекта с контролем логическои целост- 
ности зтого состоннгш. Своиства бнвагот необобгценними (распространеннни 
случаи) и обобгценними (встречаготси редко, в основном в классах коллекции). 
Подробнее о своиствах см. главу 10. 

□ Собмтие — механизм статических собнтии позволнет типу отправлитБ уве- 
домленгш статическим или зкземплирннм методам. Механизм зкземшшрних 
(нестатических) собнтии позволлет обвекту поснлатБ уведомление статиче- 
скому или зкземплнрному методу. Собнтгш обнчно инициируготсц в ответ на 
изменение состолнгш типа или обвекта, порождагогцего собнтие. Собнтие со- 
стоит из двух методов, позволигогцих статическим или зкземплирним методам 
регистрироватБ и отменитБ регистрациго (подписку) на собнтие. Помимо зтих 
двух методов, в собнтилх обнчно исполБзуетсл поле-делегат длл управленгш 
набором зарегистрированнБгх методов. Подробнее о собљптшх см. главу 11. 

□ Тип позволлет определнтБ другие вложеннБге в него типбг. 06 бгчно зтот под- 
ход применнетсл длл разбиенгш болпшого, сложного типа на неболБшие блоки 
с целБго упроститБ его реализациго. 

Егце раз подчеркну, что целн даннои главБг состоит не в подробном описании 
различнБгх членов, а в изложении обгцих принципов и обБнснении сходнбгх аспек- 
тов .')т их членов. 

Независимо от исполвзуемого нзБгка программировангш, компилитор должен об- 
работатв исходнбш код и создатк метаданнБге и IL -код длн всех членов типа. Формат 
метаданнБгх един и не зависит от ввгбранного изнгка программировангш — именно 
позтому CLR назБгвагот обгцелзиковоп исполннгогцеи средои. Метаданннге — зто 
стандартнаи информацгш, которуго предоставлигот и исполвзугот все лзбгки, по- 
зволни коду на одном нзвгке программировангш без проблем обрагцатвсн к коду на 
совершенно другом нзвгке. 

СтандартнБпг формат метаданнБгх также исполБзуетсл средои CLR длн опре- 
деленгш порлдка поведенил констант, полеи, конструкторов, методов, своиств 
и собвгтии во нрсм 'А вБшолненгш. Короче говорн, метаданнвге — зто клгоч ко всеи 
платформе разработки Microsoft .NET Framework; они обеспечивагот интеграциго 
изБгков, типов и обвектов. 

В следугогцем примере на C# показано определение типа со всеми возможнбгми 
членами. Зтот код успешно компилируетсл (не без предупреждении), но полбзбг от 



188 Глава 6. OcHOBHbie сведенил о членах и типах 


него немного — он всего линњ демонстрирует, как компилитор транслирует такои 
тип и его членм в метаданнме. Егце раз напомнго, что каждми из членов в отделБ- 
ности деталБно рассмотрен в следугогцих главах. 
using System; 

public sealed class SomeType { //1 

// Вложеннни класс 

private class SomeNestedType { } //2 

// Константа, неизменлемое и статическое изменнемое поле 
// Constant, readonly, and static read/write field 
private const Int32 c_SomeConstant = 1 ; 

private readonly String m_SomeReadOnlyField = "2"; 
private static Int32 s_SomeReadWriteField = 3; 

// Конструктор типа 


static SomeType() { } 

// 

6 

// Конструкторт зкземпллров 



public SomeType(Int32 х) { } 

// 

7 

public SomeType() { } 

// 

8 

// Зкземпллрнми и статическии метод^ 



private String InstanceMethod( ) { return null; } 

// 

9 

public static void Main() {} 

// 

10 

// Необобшенное зкземпллрное своиство 



public Int32 SomeProp { 

// 

11 

get { return 0; } 

// 

12 

set { } 

} 

// 

13 

// Обобтенное зкземпллрное своиство 



public Int32 thisfString s] { 

// 

14 

get { return 0; } 

// 

15 

set { } 

} 

// 

16 

// Зкземплнрное собмтие 



public event EventHandler SomeEvent; 

// 

17 


} 


// 3 
// 4 
// 5 


После компилнции типа можно просмотретв метадашњ 1 С с помогцкго утилитБ 1 
ILDasm.exe (рис. 6.1). 

ЗаметБте, что компилнтор генерирует метаданнБШ длл всех членов типа. На самом 
деле, длн некоторБ1хчленов, например длл собвгтил (17), компилнтор создает допол- 
нителБНБ1е членБ 1 (поле и два метода) и метаданнвге. На данном зтапе не требуетсл 
точно пониматв, что изображено на рисунке, но по мере чтенгш следугогцих глав л 
рекомендуго возврагцатБСн к зтому примеру и смотретк, как определлетсл тот или 
инои член и как зто влгшет на метаданнвге, генерируемБге компшштором. 
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Рис. 6.1. Метаданнне, полученнне с помошдбк) утилитБ! ILDasm.exe 
длл приведенного примера 


Видимостб типа 

При определении типа с видимостбго в рамках фаила, а не другого типа его можно 
сделатБ откритим (public) или внутренним (internal). ОткрБ1ТБш тип доступен 
лгобому коду лкзбои сборки. Внутреннии тип доступен толбко в тои сборке, где он 
определен. По умолчаншо компилптор C# делает тип внутренним (с более огра- 
ниченнои видимостбкз). Вот несколБКО примеров. 

using System; 

// OTKpbiTbin тип доступен из либои сборки 
public class ThisIsAPublicType { ... } 

// Внутреннии тип доступен толбко из собственнои сборки 
internal class ThisIsAnIntennalType { ... } 

// Зто внутреннии тип, так как модификатор доступа не указан лвно 
class ThisIsAlsoAnInternalType { ... } 


Дружественнме сборки 

Представвте себе следукпцуго ситуациго: в компании еств группа А, определнгогцаи 
набор полезнБ 1 х типов в однои сборке, и группа Б, исполБзугогцаи зти типбг По 
разнБш причинам, таким как индивидуалБНБ1е графики работБ1, географическаи 
разобгценностБ, различнБ1е источники финансировангш или структурБ1 подотчет- 
ности, зти группБг не могут разместитБ все свои типб1 в единои сборке; вместо зтого 
в каждои группе создаетси собственнвш фаил сборки. 
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Чтобм сборка группм Б могла исполћзоватБ типб1 rpynnbi А, группа А должна 
определитБ все нужнвге второи группе типб1 как открБ1ТБ1е. Однако зто означает, 
что зти типб1 будут доступнБ 1 абсолготно всем сборкам. В резулвтате разработчики 
другои компании смогут написатк код, исполБзугогции обгцедоступнБге типбг, а зто 
нежелателБно. Вполне возможно, в полезнвгх типах деиствугот определеннБге усло- 
вгш, которвш должна соблгодатБ группа Б при написании кода, исполБзугогцего типбг 
группБг А. То естБ нам необходим способ, которБш 6бг позволил группе А определитв 
свои типбг как внутренние, но в то же времн предоставитв группе Б доступ к зтим 
типам. Длл таких ситуации в CLR и C# предусмотрен механизм дружественних 
сборок (friend assemblies). Кстати говори, он пригодитсн егце и в ситуации со сбор- 
кои, содержагцеи код, которвпг вБшолннет модулБНБге тестБг с внутренними типами 
другои сборки. 

В процессе созданин сборки можно указатв другие сборки, которкге она будет 
считатБ «друзБнми», — длл зтого служит атрибут InternalsVisibleTo, опреде- 
леннБш в пространстве имен System . Runtime . CompilerServices. У атрибута еств 
строковБш параметр, определнгогцгш имн дружественнои сборки и ее открвгтБш клгоч 
(передаваеман атрибуту строка не должна содержатв информациго о версии, регио- 
налБНБгх стандартах или архитектуре процессора). ЗаметБте, что дружественнБге 
сборки получагот доступ ко всем внутренним типам сборки, а также к внутренним 
членам зтих типов. Приведем пример сборки, которан обБнвлнет дружественнвши 
две другие сборки со строгими именами Wintellect и Microsoft: 

using System; 

using System.Runtime.CompilerServices; // Длч атрибута InternalsVisibleTo 

// Внутренние типи зтои сборки доступни из кода двух следутцих сборок 
// (независимо от версии или регионалвних стандартов) 

[assembly:InternalsVisibleTo("Wintellect., PublicKey=12345678 .. .90abcdef")] 
[assembly:InternalsVisibleTo("Microsoft, PublicKey=b77a5c56...1934e089")] 

internal sealed class SomeInternalType { ... } 
internal sealed class AnotherInternalType { ... } 

ОбратитБСн из дружественнои сборки к внутренним типам представленнои здесв 
сборки оченБ просто. Например, дружественнан сборка Wintellect с открвгтБш клго- 
чом 12345678...90abcdef может обратитксл к внутреннему типу SomeInternalType 
представленнои сборки следугогцим образом: 

using System; 

internal sealed class Foo { 

private static Object SomeMethod() { 

// Зта сборка Wintellect получает доступ к внутреннему типу 
// другои сборки, как если бм он бмл откритмм 
SomeInternalType sit = new SomeInternalType(); 
return sit; 

} 

} 
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Посколћку внутренние членв 1 принадлежатцих сборке типов становлтсл до- 
ступнмми длл дружественнмх сборок, следует оченв осторожно подходитб к опре- 
делениго уровнн доступа, предоставлнемого членам своего типа, и обЂнвленшо 
дружественнБ 1 х сборок. ЗаметБте, что при компилиции дружественнои (то еств не 
содержашеи атрибута InternalsVisibleTo) сборки компилитору C# требуетсл за- 
даватБ параметр /out : фапл. Он нужен компилнтору, что6б1 узнатБ имн компилиру- 
емои сборки и определитБ, должна ли резулБтиругогцан сборка 6б1тб дружественнои. 
Можно подуматБ, что компилитор C# в состоинии самостонтелБно вбшснитб зто 
имн, так как он о6бгчно самостолтелБно определлет имл вбгходного фаила; однако 
компилнтор «узнает» имн вбгходного фаила толбко после завершенин компиллции. 
Позтому требование указвшатБ зтот параметр позволнет значителвно повбгситб 
производителБностБ компилнции. 

Аналогично, при компилнции модули (в противоположностБ сборке) с параметром 
/t : mod ule, которБпг должен стати частБго дружественнои сборки, необходимо также 
исполБЗОватБ параметр /moduleassemblyname : строка компшштора С#. Последнии 
параметр говорит компшштору, к какои сборке будет относитбсн модулБ, что6б1 тот 
разрешил коду зтого модули обрагцатБСн к внутренним типам другои сборки. 


Доступ к членам типов 

При определении члена типа (в том числе вложенного) можно указатв модификатор 
доступа к члену. МодификаторБг определигот, на какие члешл можно ссБшатБСи из 
кода. В CLR имеетсл собственнБш набор возможнбгх модификаторов доступа, но в 
каждом изБгке программировангш сугцествугот свои синтаксис и терминБг. Напри- 
мер, термин Assembly в CLR указвгвает, что член доступен изнутри сборки, тогда 
как в C# длн зтого исполБзуетсл клгочевое слово internal. 

В табл. 6.1 представлено шеств модификаторов доступа, определнгогцих уровенв 
ограниченгш — от максималБного (Private) до минималБного (Public). 


Таблица 6.1. МодификаторБ! доступа к членам 


CLR 

C# 

Описание 

Private (закрмтвш) 

private 

Доступен толбко методам в определлкнцем типе 
и вложеннмх в него типах 

Family (родовои) 

protected 

Доступен толбко методам в определлкицем типе 
(и вложеннБк в него типах) или в одном из его 
производнБ1х типов независимо от сборки 

Family and 

Assembly (родовои 
и сборочнв 1 и) 

(не поддер- 
живаетсн) 

Доступен толбко методам в определлкмцем типе 
(и вложеннБгх в него типах) и производнвк ти- 
пах в определлкмцеи сборке 


продолжение 
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Таблица6.1 ( продолжение) 


CLR 

C# 

Описание 

Assembly (сбороч- 
нни) 

internal 

Доступен толвко методам в определнгогцеи 
сборке 

Assembly or Family 
(сборочнми или 
родовои) 

protected 

internal 

Доступен толвко методам вложенного типа, про- 
изводного типа (независимо от сборки) и лго- 
бнм методам определнгогцеи сборки 

Public (открнтни) 

public 

Доступен всем методам во всех сборках 


Разумеетсл, дли полученин доступа к члену типа он должен бљпт, определен 
в видимом типе. Например, если в сборке А определен внутреннии тип, имекнции 
открмтми метод, то код сборки В не сможет вмзвати открмтми метод, поско.твку 
внутреннии тип сборки А недоступен из В. 

В процессе компилнции кода компилитор нзмка проверлет корректноств обрапде- 
нин кода к типам и членам. Обнаружив некорректнуго ссмлку на какие-либо типм 
или членм, компилитор информирует об ошибке. Помимо зтого, во времи вмпол- 
ненин JIT -компилнтор тоже провернет корректноств обрагценин к полнм и методам 
при компилнции IL -кода в процессорнме командм. Например, обнаружив код, не- 
правилмш пмтакпциисн обратитисн к закрмтому полк> или методу, Ј1Т-компилнтор 
генерируетисклгочение FieldAccessException или MethodAccessException соот- 
ветственно. 

Верификацин IL -кода гарантирует правилвноств обработки модификаторов до- 
ступа к членам в период вмполненгш, даже если компилнтор нзмка проигнорировал 
проверку доступа. Другаи, более вероитнаи возможности заклгочаетси в компили- 
ции кода, обрагцагогцегосн к открмтому члену другого типа (другои сборки); если 
в период вмполненгш загрузитси другаи версии сборки, где модификатор доступа 
открмтого члена заменен заиџаценним (protected) или закритшм (private), вери- 
фикации обеспечит корректное управление доступом. 

Если модификатор доступа ивно не указан, компшштор C# обмчно (но не всег- 
да) вмберет по умолчаниго закрмтми — наиболее строгии из всех. CLR требует, 
чтобм все членм интерфеисного типа бмли открмтмми. Компиллтор C# знает об 
зтом и запрегцает программисту лвно указмватв модификаторм доступа к членам 
интерфеиса, просто делаи все членм открмтмми. 


ПРИМЕЧАНИЕ 

Подробнее о правилах примененил в C# модификаторов доступа ктипам и членам, 
а также о том, какие модификаторм C# вмбирает по умолчанико в зависимости от 
контекста обвлвленил, рассказмваетсл в разделе «Declared Accessibility» специфи- 
кации лзмка С#. 
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Более того, как видно из табл. 6.1, в CLR естБ модификатор доступа родовоп 
и сборочнип. Но разработчики C# сочли зтот атрибут лишним и не вклгочили 
В ИЗБ1К С#. 

Если в производном типе переопределлетсл член базового типа, компилнтор C# 
требует, чтобћ1 у членов базового и производного типов 6бши одинаковБШ модифи- 
каторБ 1 доступа. То сстб если член базового класса нвлнетсл загциценним, то и член 
производного класса должен 6б1тб загцигценним. Однако зто ограничение нзБжа С#, 
а не CLR. При наследовании от базового класса CLR позволлет снижатБ, но не по- 
вБшатБ ограниченин доступа к члену. Например, загцигценнип метод базового класса 
можно переопределитБ в производном классе в откритип, но не в закритип. Дело 
в том, что полБЗОвателБ производного класса всегда может получитБ доступ к методу 
базового класса путем приведенгш к базовому типу. Если 6bi среда CLR разрешала 
устанавливатБ более жесткие ограниченгш на доступ к методу в производном типе, 
то зти ограниченгш 6бг злементарно обходилисБ. 


Статические классн 

Сугцествугот классБг, не предназначеннБге длл созданин зкземплнров, например 
Console, Math, Environment и ThreadPool. У зтих классов естБ толбко статические 
методБг. В сугцности, такие классБг сугцествугот лишб длл группировки логиче- 
ски свнзаннБгх членов. Например, класс Math обБединиет методБг, вБшолннгогцие 
математические операции. В C# такие классБг определиготсл с клгочевБгм словом 
static. Его разрешаетсн применчтБ толбко к классам, но не к структурам (значимБш 
типам), посколБку CLR всегда разрешает создаватБ зкземплнрБг знлчимбгх типов, 
и нет способа обоити зто ограничение. 

Компилитор налагает на статическии класс рнд ограничении. 

□ Класс должен 6бгтб прнмБш потомком System . Ob ј ect — наследование лгобому 
другому базовому классу лишено смвгсла, посколбку наследование применимо 
толбко к обЂсктам, а создатБ зкземплир статического класса невозможно. 

□ Класс не должен реализоввшатБ никаких интерфеисов, посколвку методБг ин- 
терфеиса можно вБИБшатБ толбко через зкземплирБг класса. 

□ В классе можно определнтБ толбко статические членБг (поли, методБг, своиства 
и со6бгтгш). JIro6bie зкземплнрнБге членБг вБгзовут ошибку компилицгш. 

□ Класс нелБЗи исполБЗОватБ в качестве полн, параметра метода или локалБнои 
переменнои, посколБку зто подразумевает сугцествование переменнои, ссбг- 
лагогцеисл на зкземплир, что запрегцено. Обнаружив подобное обрагцение со 
статическим классом, компилитор вернет сообгцение об ошибке. 

Приведем пример статического класса, в котором определенБг статические членБЦ 
сам по себе класс не представллет практического интереса. 
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using System; 

public static class AStaticClass { 
public static void AStaticMethodQ { } 

public static Stning AStaticProperty { 
get { return s_AStaticField; } 
set { s_AStaticField = value; } 

} 

private static String s_AStaticField; 
public static event EventHandler AStaticEvent; 

} 

Ha рис. 6.2 приведен резулкгат дизассемблированил с помошвго утилитм 
ILDasm.exe библиотечнои (DLL) сборки, полученнои при компилнции приведен- 
ного фрагмента кода. Как видите, определение класса с клгочевмм словом static 
заставлнет компилнтор C# сделатБ зтот класс абстрактнћш (abstract) и запеча- 
таннБш (sealed). Более того, компилитор не создает в классе метод конструктора 
зкземплнров (. ctor). 


/7 sc.dll - IL DASM Г^~ГвЦ^| 

File View Help 

B -a> sc.dll 

!••••• ► N Д N I F E 5 T 


A5taticClass 


► .class public abstract auto ansi sealed beforefieldinit 
^ AStaticEvent: private static dass [mscorlib]System.EventHandler 
ф s_A5taticField : private static string 

□ AStaticMethod : void() 

□ add_AStaticEvent : void(dass[mscorlib]System.EventHandler) 

□ get_AStaticProperty : string() 

□ remove_AStaticEvent: void(dass [mscorlib]System.EventHandler) 

□ set_AStaticProperty : void(string) 

V AStaticEvent: [mscorlib]System.EventHandler 
Д AStaticProperty : string() 


.assembly sc 



Рис. 6.2. Статическии класс в ILDasm.exe 


Частичнне классн, структурн 
и интерфеисм 


Клгочевое слово partial говорит компиллтору С#, что исходнбш код класса, 
структурБ! или интерфеиса может располагатБСн в несколвких фаилах. Компшгатор 
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об'Р,слипж‘т все частичнв1е фаилм класса во времи компилиции; CLR всегда рабо- 
тает с полнмми определениими типов. Естб три оспонимс причинм, по которвш 
исходнми код разбиваетсн на несколБКО фаилов. 

□ Управление версинми. Представвте, что определение типа содержит болБшои 
обкем исходного кода. Если зтот тип будут одновременно редактироватБ два 
программиста, по завершении работБ1 им придетсл каким-то образом обБединнтБ 
свои резулвтатБ 1 , что весБма неудобно. Клгочевое слово pantial позволнет раз- 
6 итб ИСХОДНБ 1 И код типа на несколкко фаилов, что 6 б 1 один и тот же тип могли 
одновременно редактироватв несколБКО программистов. 

□ Разделение фаила или структурБ1 на логические модули внутри фаила. 

Иногда требуетсл создатв один тип длл решенил разнБгх задач. Длл упро- 
гценгш реализацгш н иногда о6бивлиго одинаковБге типбг повторно внутргг 
одного фаила. Затем в каждои частгг такого тггпа л реализуго по одному 
функционалБному аспекту тггпа со всемгг его поллмгг, методами, своиства- 
мгг, со6бгтгшми и т. д. Зто позволлет мне упроститв наблгодение за членами, 
обеспечггвагогцггми единуго функционалвностБ и обБединеннБгми в группу. 
Л также могу легко закомментироватв частичнБги тггп с целБго удаленил всеи 
функционалБности ггз класса гглгг заменкг ее другои (путем ггсполБЗОванил 
новои частгг частичного тггпа). 

□ Разделители кода. При создании в Microsoft Visual Studio нового проекта 
Windows Forms гглгг Web Forms некоторвге фаилвг с исходнбгм кодом создаготсл 
автоматически. Онгг назБгваготсл шаблоннБгми. Пргг ггсполБЗОвангги конструк- 
торов форм Visual Studio в процессе созданил и редактировангш злементов 
управлении формвг автоматически генерирует весв необходимБги код и по- 
мегцает его в отделвнБге фаилБг. Зто значителБно повБгшает продуктивностБ 
работБг. РанБше автоматически генерируемБги код попадал в тот же фаил, где 
программист пггсал свои исходнбги код. Однако при случаином изменении 
сгенерированного кода конструктор форм переставал корректно работатв. На- 
чггнаи с Visual Studio 2005, пргг создании нового проекта Visual Studio создает 
два исходнбгх фаила: одггн предназначен длн программиста, а в другои помегца- 
етсл код, создаваемБги редактором форм. В резулктате вероитностБ случаиного 
измененип генерируемого кода сугцественно снижаетсл. 

Клгочевое слово partial применпетсл к тггпам во всех фаилах с определением 
тггпа. Пргг компгглицгги компилитор обБединнет зти фаилБг, и готовбпг тггп помегца- 
етсл в резулБтиругогцгш фаил сборкгг с расширением ехе илгг dll (или в фаил модулн с 
расширением netmodule). Как уже отмечалосв, частичнБге тггпбг реализуготсл толбко 
компилптором С#; позтому все фаилвг с исходнбгм кодом такггх тггпов необходимо 
пггсатв на одном изБгке и компилироватБ ггх вместе как едггнБш блок компгглицгги. 
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Компонентм, полиморфизм и версии 

ОбЂектно-ориентированное программирование (ООП) сушествует уже много 
лет. В поздние 70-е и ранние 80-е годм обЂектно-ориентированнме приложенил 
бмли намного менвше по размеру, и весЂ код приложенгш разрабатмвалсн в однои 
компании. Разумеетсл, в то времл уже бмли операционнме системм, позволнгогцие 
приложенгшм по максимуму исполЂЗОватЂ их возможности, но современнме ОС 
предлагагот намного болвгне функции. 

Сложностђ программного обеспеченгш сугцественно возросла, к тому же полђ- 
зователи требугот от приложении богатмх функционалвнмх возможностеи — гра- 
фического интерфеиса, менго, различнмх устроиств ввода-вмвода (ммшђ, принтер, 
планшет), сетевмх функции и т. п. Все зто привело к сугцественному расширениго 
функционалЂности операционнмх систем и платформ разработки в последние 
годм. Более того, сеичас уже не представлнетсл возможнмм или зффективнмм 
писатв приложение «с нули» и разрабатмватЂ все необходимме компонентм само- 
столтелЂно. Современнме приложенгш состолт из компонентов, разработаннмх 
многими компангшми. Зти компонентм обЂединлготсн в единое приложение 
в рамках парадигмм ООП. 

При компонентнои разработке приложении (Component Software Programming, 
CSP) идеи ООП исполЂзуготсл на уровне компонентов. Ниже перечисленм неко- 
торме своиства компонента. 

□ Компонент (сборка в .NET) можно публиковатв. 

□ Компонентм уникалвнм и идентифицируготси по имени, версии, регионалЂнмм 
стандартам и открмтому клгочу. 

□ Компонент сохраннет свого уникалЂностЂ (код однои сборки никогда статически 
не свнзмваетси с другои сборкои — в .NET применчетсч толђко динамическое 
свнзмвание). 

□ В компоненте всегда четко указана зависимоств от других компонентов (ссм- 
лочнме таблицм метаданнмх). 

□ В компоненте документированм его классм и членм. В C# даже разрешаетсл 
вклгочатв в код компонента ХМТ-документациго — длн зтого служит параметр 
/doc команднои строки компшштора. 

□ В компоненте определнготсн требуемме разрешенгш на доступ. Длн зтого в CLR 
сугцествует механизм загцитм доступа к коду (Code Access Security, CAS). 

□ Опубликованнми компонентом интерфеис (обЂектнан моделк) не измениетси 
во всех его служебнмх версилх. Служебноп версиеп (servicing) назмвагот новуго 
версиго компонента, обратно совместимуго с оригиналЂнои. Обмчно служебнаи 
версил содержит исправленгш ошибок, исправленгш системм безопасности 
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и неболБшие корректировки функционалБности. Однако в нее нелћзи добавлнтБ 
новбш зависимости или разрешении безопасности. 

Как видно из последнего пункта, в компонентном программировании болБшое 
внимание уделигот управлениго версиими. В компонентБ 1 вноситсн изменешш, 
к тому же они поставлиготсн в разное времн. НеобходимостБ управленин версгшми 
сугцественно усложниет компонентное программирование по сравнениго с ООП, 
где все приложение пишет, тестирует и поставлиет одна компашш. 

В .NET номер версии состоит из четБфех частеи: основного (major) и дополни- 
телтого (minor) номеров версии, номера построенил (build) и номера редакции 
(revision). Например, у сборки с номером 1.2.3.4 основнои номер версии — 1, до- 
полнителБНБш номер версии — 2, номер построенгш — 3 и номер редакции — 4. 
Основнои и дополнителБНБш номера обишно определигот уникалБностБ сборки, 
а номера построенгш и редакции указБшагот на служебнуго версиго. 

Допустим, компангш поставила сборку версии 2.7.0.0. Если впоследствгш по- 
требуетси вБгауститБ сборку с исправленнБши ошибками, вБшускагот новуго сборку, 
в которои изменнгот толбко номера построенгш и редакции, например 2.7.1.34. То 
естБ сборка нвлиетсн служебнои версиеи и обратно совместима с оригиналБнои 
(2.7.0.0). 

В то же времи, если компангш ввшустит новуго версиго сборки, в которуго вне- 
сенБ1 значителБНБШ измененгш, а обратнан совместимостБ не гарантируетсн, нужно 
изменитБ основнои и/или дополнителБНБпг номер версии (например, 3.0.0.0). 

ПРИМЕЧАНИЕ 

R описал то, как вам следует относитбсл к номерам версии. К сожалениго, CLR не 
работаетс номерами версии поатим правилам. Если сборказависитот версии 1.2.3.4 
другои сборки, CLR будет nbiTaTbcn загрузитБтолБко версик) 1.2.3.4 (если толбко не 
задеиствоватБ механизм перенаправленил свлзБ 1 ванил). 


После ознакомленгш с порндком присвоенгш номера версии новому компоненту 
самое времн узнатв о возможностнх CLR и нзбшов программировангш (таких как 
С#), позволнгогцих разработчикам писатБ код, устоичивБпг к измененгшм компо- 
нентов. 

Проблемвг управленгш версиими вознггкагот, когда тип, определеннБиг в одном 
компоненте (сборке), исполБзуетсн в качестве базового класса длл типа другого 
компонента (сборки). Лсно, что измененгш в базовом классе могут повлгштб на 
поведенгге проггзводного класса. Зтгг проблемвг особенно характерннг длн по- 
лиморфизма, когда в производном тггпе переопределнготсн вггртуалБНБге методБг 
базового типа. 

В C# длн тггпов и/или их членов естБ пнтб клгочевБ 1 х слов, влгшгогцих на управ- 
ление версгшми, причем они напрнмуго свнзанБ 1 с соответствугогцими возможностп- 
ми CLR. В табл. 6.2 перечисленБ 1 k. iio'icbi.ic слова С#, относигциесн к управлениго 
версгшми, и описано их влгшние на определенгге типа или члена типа. 
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Таблица 6.2. Клкзчевне слова C# и их влилние на управление 
версинми компонентов 


КлкЈчевое 
слово C# 

Тип 

Метод/Своиство/Собнтие 

Константа/Поле 

abstract 

Зкземпллрм такого 
типа создаватБ нелБЗл 

Член необходимо переопре- 
делитБ и реализоватБ в произ- 

водном типе — толбко после 

зтого можно создаватБ зкзем- 

пллрм производного типа 

(запрегцено) 

virtual 

(запрегцено) 

Член может переопределлтБ- 
сл в производном типе 

(запрегцено) 

override 

(запрегцено) 

Член переопределлетсл в про- 
изводном типе 

(запрегцено) 

sealed 

Тип НеЛБЗЛ исполб- 

зоватБ в качестве 
базового при насле- 
довании 

Член нелБЗл переопределитБ 
в производном типе. Зто 
клгочевое слово может при- 
менлтБСл толбко к методу, 
переопределлкпцему вирту- 

алБНБш метод 

(запрегцено) 

new 

ПрименителБно к вложенному типу, методу, своиству, собштиго, константе 
или полго означает, что член никак не свлзан с похожим членом, которвги 
может сушествоватв в базовом класс 


О назначении и исполћзовании зтих клгочевмх слов рассказмваетсл в разделе 
«Работа с виртуалвнмми методами при управлении версинми типов», но прежде 
необходимо рассмотретБ механизм вБ130ва виртуалБНБ 1 х методов в CLR. 

Bbi 30 B виртуалБнмх методов, своиств и собмтии в CLR 

В зтом разделе речБ идет толбко о методах, но все сказанное относитсл и к вирту- 
алБНБш своиствам и собвтшм, посколвку они, как показано далее, на самом деле 
реализуготсл методами. 

МетодБ 1 содержат код, вбшолниготции некоторБ 1 е деиствии над типом (стати- 
ческие методБ 1 ) или зкземплиром типа (нестатические). У каждого метода естк 
имн, сигнатура и возврагцаемБпг тип, коториш может 6 б 1 тб пустБ 1 м (void). У типа 
может 6 б 1 тб несколБКО методов с одним именем, но с разнвш числом параметров 
или разнвши возврагцаемБши значенгшми. Можно также определитБ два метода 
с одним и тем же именем и параметрами, но с разнвши типами возврагцаемого 
значенгш. Однако зта «возможностб» 6 олбшгшством нзбгков не исполвзуетсл (за 
исклгочением IL) — все они требугот, чтобвг методвг с одинаковБш именем различа- 
лисб параметрами, а возврагцаемое значение при определенгш уникалвности метода 
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игнорируетси. Впрочем, благодари операторам преобразовании типов в нзмке C# 
зто ограничение смнгчаетсл (см. главу 8). 

Определим класс Employee с тремн различнмми вариантами методов. 

internal class Employee { 

// НевиртуалБнни акземпллрнми метод 
public Int32 GetYearsEmployed { ... } 

// Виртуалвнми метод (виртуалвнми - значит, зкземпллрнми) 
public virtual String GetProgressReport { ... } 

// Статическии метод 

public static Employee Lookup(String name) { ... } 

} 

При компилнции зтого кода компилнтор помегцает три записи в таблицу опре- 
делении методов сборки. Каждал записв содержит флаги, указмвакчцие, нвлнетси 
ли метод зкземплирнмм, виртуалБнмм или статическим. 

При компилнции кода, ссБшакзгцегосл на зти методБ 1 , компиллтор проверлет 
флаги в определении методов, что 6 б 1 вбшснитб, какои IL -код нужно вставитк длл 
корректного вБВОва методов. В CLR еств две инструкции дли ввиова метода: 

□ Инструкции call исполвзуетсл длл вБ130ва статических, зкземплирнБ 1 х и вир- 
туалвнБ 1 х методов. Если с помогцбкз зтои инструкции вБ13Б1ваетсл статическии 
метод, необходимо указатв тип, в котором определлетсл метод. При ввгзове 
зкземплнрного или виртуалвного метода необходимо указатн переменнуго, 
ссБшагогцугоси на обвект, причем в call подразумеваетсл, что зта переменнан 
не равна null. Иначе говорл, сам тип переменнои указБ 1 вает, в каком типе 
определен необходимвш метод. Если в типе переменнои метод не определен, 
провернготсн базовБШ типбг Инструкцгш call часто служит длн невиртуалБного 
вБ130ва виртуалБного метода. 

□ Инструкцгш callvint исполБзуетсл толбко дли вкгзова зкземплнрнвгх и вир- 
туалвнБгх (но не статических) методов. При ввгзове необходимо указатв пере- 
меннуго, ссБшагогцугосн на обвект. Если с помогцбго зтои инструкции вБгзБгваетсн 
невиртуалБНБпг зкземплнрнБпг метод, тип переменнои показБгвает, где определен 
необходимБш метод. При исполБЗОвангш callvirt длл ввгзова виртуалвного 
зкземплнрного метода CLR определлет настоигции тип обвекта, на которБги 
ссБшаетси переменнаи, и внгзБшает метод полиморфно. При компгшнцгш такого 
вБгзова JIT -компгшлтор генерирует код длл проверки значенгш переменнои — 
если оно равно null, CLR сгенерирует исклгочение NullReferenceException. 
Из-за зтои дополнителБнои проверки инструкцгш callvirt ввшолннетсл не- 
много медленнее, чем call. Проверка на null ввшолшгетси даже при вБгзове 
невиртуалБного зкземплнрного метода. 

Даваите посмотрим, как зти гшструкцгш исполБзуготсл в С#. 
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using Systemj 

public sealed class Program { 
public static void Main() { 

Console.WriteLine(); // Вћвов статического метода 

Object o = new Object(); 

o.GetHashCode(); // Вћвов виртуалБного зкземплврного метода 
o.GetType(); // Вћвов невиртуалвного зкземпллрного метода 

} 

} 

После компилнции резулБтирукшдии IL -код вмгллдит следуклцим образом. 

.method public hidebysig static void Main() cil managed { 

. entrypoint 

// Code size 26 (0xla) 

.maxstack 1 

.locals init (object o) 

IL_0000: call void System.Console::WriteLine() 

IL_@005: newobj instance void System.Object::.ctor() 

IL_@00a: stloc.0 
IL_@00b: ldloc.0 

IL_@00c: callvirt instance int32 System.Object::GetHashCode() 

IL_@011: pop 
IL_@012: ldloc.0 

IL_@013: callvirt instance class System.Type System.Object::GetType() 

IL_@018: pop 
IL_@019: ret 

} // end of method Program::Main 

ПосколБку метод WriteLine нвлиетсл статическим, компилнтор C# исполБзует 
длл его вмзова инструкцшо call. Длн вмзова виртуалБного метода GetHashCode 
применпетсл инструкции callvint. Наконец, метод GetType также вБгзБшаетсл 
с помогцбк) инструкции callvint. Зто вблллдит странно, посколнку метод GetType 
невиртуалБНБп!. Тем не менее код работает, потому что во времи ЈТТ-компилиции 
CLR знает, что GetType — зто невиртуалвнБш метод, и вБИБшает его невиртуалБно. 

Разумеетсл, возникает вопрос: почему компилнтор C# не исполвзует инструкциго 
call? Разработчики C# решили, что JIT -компилитор должен генерироватн код, 
которкш проверлет, не равен ли null вБШБшакшдии обвект. Позтому вб130вб 1 не- 
виртуалБНБ1х зкземплнрнБ1х методов вбшолннјотсн чутн медленнее, чем могли 6 hi - 
а также то, что следугогцгш код в C# ввшовет исклгочение NullRef enenceException, 
хотл в некоторв 1 х нзБшах все работает отлично. 
using System; 

public sealed class Program { 

public Int32 GetFive() { return 5; } 
public static void Main() { 

Program p = null; 

Int32 х = p.GetFive(); // B C# видаетсп NullReferenceException 

} 

} 
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Теоретически с отим кодом все в порндке. Хотн переменнап р равна null, длл 
вмзова невиртуалћного метода GetFive среде CLR необходимо узнатБ толбко тип р, 
а зто Program. При вмзове GetFive аргумент this равен null, но в методе GetFive 
он не исполБзуетсл, позтому исклгоченин нет. Однако компилитор C# вместо ин- 
струкции call вставлнет callvirt, позтому вБшолнение кода приведет к вБвдаче 
исклгоченгш NullReferenceException. 

ВНИМАНИЕ 

Если метод определен какневиртуалБнми, не рекомендуетсл вдалБнеишем делатђего 
виртуалБНБ1м. Причина в том, что некоторБ1е компиллторм дпч визова невиртуалБного 
метода исполБзуктт инструкцикз call вместо callvirt. Если методсделатБ виртуалБНБ1м 
и не перекомпилироватБ ссБшакхциисл на него код, виртуалБНБ 1 и метод будет вшван 
невиртуалБно, в резулБтате приложение может повести себл непредсказуемо. Если 
код, содержашии bn 30 b, написан на С#, все проидет нормалБно, посколбку в C# 
все зкземпллрнме методБ! вБ 13 нвакзтсл с помопдбкз инструкции callvirt. Flo если код 
написан на другом лзБ1ке, возможнбј проблемм. 


Иногда компилнтор вместо callvirt исполБзует дли вБ 130 ва виртуалБного 
метода команду call. Такое поведение вбгглидит странно, но следугогции пример 
показБшает, почему зто деиствителБно бћ1вает необходимо. 
internal class SomeClass { 

// ToString - виртуалБнни метод базового класса Object 
public override String ToStringO { 

// Компиллтор исполБзует команду call длл невиртуалБного вмзова 
// метода ToString класса Object 

// Если 6bi компилптор вместо call исполизовал callvirt, зтот 

// метод продолжал бн рекурсивно вмзнватБ сам себл до переполненип стека 

return base.ToString(); 

} 

} 

При вБдзове виртуалБного метода base . ToString компилитор C# вставлнет 
команду call, что6бг метод ToString базового типа вБгзБшалси невиртуалБно. Зто 
необходимо, ведБ если ToString вБгзватБ виртуалБно, вбгоов будет вбшолннтбсн 
рекурсивно до переполненгш стека потока — что, разумеетси, нежелателвно. 

КомпиллторБг стремлтсл исполБЗОватБ команду call при вБгзове методов, опреде- 
леннБгх значимБши типами, посколнку они запечатанБг. В зтом случае полиморфизм 
невозможен даже длл виртуалвнБгх методов, и вбгзов ввшолннетси бБгстрее. Кроме 
того, сама природа зкземплнра значимого типа гарантирует, что он никогда не будет 
равен null, позтому исклгочение NullRef erenceException не возникнет. Наконец, 
длл виртуалБного вБгзова виртуалвного метода значимого типа CLR необходимо 
получитБ ссБшку на обвект значимого типа, чтобкг восполБЗОватБСи его таблицеи 
методов, а зто требует упаковки значимого типа. Упаковка повБпнает нагрузку на 
кучу, увеличиван частоту сборки мусора и снижаи производителвностБ. 
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Независимо от испо. њзуемои длн вмзова зкземплирного или виртуалБного 
метода инструкции — call или callvint — зти методм всегда в первом параметре 
получакп скрмтми аргумент this, ссмлагогциисл на обвект, с котормм произво- 
длтсл деиствии. 

При проектировании типа следует стремитБСн свести к минимуму количество 
виртуалБНБгх методов. Во-перввгх, виртуалБНБпг метод вБгзБшаетсн медленнее невир- 
туалБного. Во-вторБ 1 х, JIT -компилнтор не может подставлнтБ (inline) виртуалБНБге 
методБг, что также ухудшает производителБностБ. В-третБих, как показано далее, 
iutprya. ibin.ic мстод |.1 затрудннгот управление версгшми компонентов. В-четвертвгх, 
при определении базового типа часто создаетсл набор перегруженнвгх методов. 
Чтобвг сделатБ их полиморфнБши, лучше всего сделатв наиболее сложнбш метод 
виртуалБНБш, оставив другие методвг невиртуалБНБши. Кстати, соблгодение зтого 
правила поможет управлнтв версилми компонентов, не нарушаи работу производ- 
нБгх типов. Приведем пример: 

public class Set { 

private Int32 m_length = 0 ; 

// Зтот перегруженнми метод - невиртуалБнми 
public Int32 Find(Object value) { 
retunn Find(value, 0 , m_length); 

} 

// Зтот перегруженнми метод - невиртуалБнми 
public Int32 Find(Object value, Int32 startlndex) { 
return Find(valuej startlndex, m_length startlndex); 

} 

// Наиболее функционалннми метод сделан виртуалцнмм 
// и может 6biTb переопределен 

public virtual Int32 Find(Object value, Int32 startlndex, Int32 endlndex) { 

// Здесц находитсн настовшан реализацил, которут можно переопределитц... 

} 

// Другие методн 

} 

Разумное исполвзование видимости типов 
и модификаторов доступа к членам 

В .NET Framework приложенгш состолт из типов, определеннБгх в многочисленнБгх 
сборках, созданнБгх различнБши компангшми. Зто означает практически полное 
отсутствие контролн над исполБзуемБгми компонентами и типами. Разработчику 
обкгчно недоступен исходнбш код компонентов (он может даже не знатв, на каком 
И31.1КС они написанБг), к тому же версии компонентов обновлнготси в разное вре- 
мл. Более того, из-за полиморфизма и наличгш загцигценнБгх членов разработчик 
базового класса должен доверитв коду разработчика производного класса. В свого 
очередв, разработчик производного класса должен доверитв коду, наследуемому от 
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базового класса. Зто лишб частБ ограничении, с котормми приходитсн сталкиватБСн 
при разработке компонентов и типов. 

В зтом разделе н расскажу о том, как проектироватБ типм с учетом зтих факторов. 
А если говоритБ конкретно, речБ поидет о том, как правилБно задаватћ видимостб 
типов и модификаторБ1 доступа к членам. 

В первуго очередБ при определении нового типа компилнторам следовало 6bi 
по умолчаншо делатв его запечатаннБш. Вместо зтого болБшинство компилито- 
ров (в том числе С#) поступагот как раз наоборот, считал, что программист при 
необходимости сам может запечататв класс с помогцбк) клгочевого слова sealed. 
Ббшо 6б 1 неплохо, если 6ni неправилБное, на мои взгллд, поведение, предлагаемое 
по умолчаник), в следугогцих версинх компилиторов изменилосБ. Естб три веские 
причинБ1 в полвзу исполБЗОвангш запечатаннвгх классов. 

□ Управление версинми. Если класс изначалвно запечатан, его впоследствгш 
можно сделатв незапечатаннБш, не нарушан совместимости. Однако обратное не- 
возможно, посколвку зто нарушило 6бг работу всех производнвгх классов. Кроме 
того, если в незапечатанном классе определенвг незапечатаннвге виртуалБНБге 
методБг, необходимо сохраннтн поридок внгзова виртуалвнБгх методов в новбгх 
версинх, иначе в будугцем возникнут проблемвг с производнБши типами. 

□ ПроизводителћностБ. Как уже отмечалосв, невиртуалБНБге методБг вБгзБшаготсн 
бБгстрее виртуалБНБгх, посколБку длл последних CLR во времи ввшолненгш 
проверлет тип обвекта, чтобвг вбшснитб, где находитсл метод. Однако, встре- 
тив вБгзов виртуалБного метода в запечатанном типе, JIT -компиллтор может 
сгенерироватБ более зффективнБш код, задеиствовав невиртуалБНБиг вбгзов. 
Зто возможно потому, что у запечатанного класса не может 6бгтб производнБгх 
классов. Е[апример, в следугогцем коде JIT -компилнтор может ввговатБ вирту- 
алБНБпг метод ToStning невиртуалБно: 

using System; 

public sealed class Point { 
private Int32 m_x, m_y; 

public Point(Int32 х, Int32 у) { m_x = х; m_y = у; } 

public override String ToStringO { 

return String.Format("({0}, {1})", m_x, m_y); 

} 

public static void Main() { 

Point p = new Point(3, 4); 

// Компиллтор C# вставит вдесБ инструкцин) callvirt, 

// но 31Т-компилнтор оптимизирует втот Bbi30B и сгенерирует код 
// длн невиртуалцного вмзова ToString, 

// посколБку р имеет тип Point, двлнклциисд запечатанним 
Console.WriteLine(p.ToString( )); 

} 

} 
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□ Безопасностћ и предсказуемостБ. Состонние класса должно бљт> надежно 
затитено. Если класс не запечатан, производнми класс может изменитБ его 
состоиние, восполБЗОвавшисБ незагцигценнмми полими или методами базового 
класса, изменнгогцими его доступнме незакрмтме поли. Кроме того, в произво- 
дном классе можно переопределитБ виртуалБнме методм и не вмзмватБ реали- 
зациго соответствугогцих методов базового класса. Назначаи метод, своиство 
и сообп ис виртуалБНБш, базовБш класс уступает некоторуго степенк контроли 
над его поведением и состоннием производному классу, что при неумелом обра- 
гцении может ввгзватБ непредсказуемое поведение и проблемвг с безопасностБго. 

Беда в том, что запечатаннвге классБг могут создатБ изриднБге неудобства длн 
полвзователеи типа. Разработчику приложенгш может понадобитвсн производнБги 
тип, в котором будут добавленвг дополиителБНБге полл или другаи информацин 
о состоингш. Они даже могут попБгтатБСн добавитБ в производном типе дополни- 
телвнБге методБг длн работБг с зтими полнми. Хотн CLR не предоставлнет механизма 
расширенгш уже построеннвгх типов вспомогателБНБши методами или полнми, 
вспомогателБНБге методБг можно имитироватБ при помогци методов расширенгш 
C# (см. главу 8), а длн расширенгш состоннгш обвекта может исполБЗОватБСи класс 
ConditionalWeakTable (см. главу 21 ). 

Вот несколвко правил, которвш н следуго при проектировангш классов: 

□ Если класс не предназначен длл наследовангш, н всегда лвно о6ђивлнго его 
запечатаннвш. Как уже отмечалосБ, C# и многие современнБге компиллторБг 
поступагот иначе. Если нет необходимости в предоставленгш другим сборкам 
доступа к классу, он обБнвлнетсн внутренним. К счаствго, именно так ведет себн 
по умолчаниго компилнтор С#. Если н хочу определитв класс, предназначеннБпг 
длн создангш производнБгх классов, одновременно запретив его специализациго, 
н должен переопределитв и запечататБ все виртуалБНБге методБг, которБге на- 
следует мои класс. 

□ Все 11 ол 'А даннБгх класса всегда о6бнвлнготсл закрвгтБгми, и в зтом н никогда не 
уступлго. К счаствго, по умолчаниго C# поступает именно так. Вообгце говорн, 
л 6бг предпочел, что6бг в C# осталисв толбко закркгтБге полл, а о6ђивлнтб их 
со спецификаторами protected, internal, public и т. д. 6бшо 6бг запрегцено. 
Доступ к состонниго обвекта — вернБпг путБ к непредсказуемому поведенггго 
гг проблемам с безопасноствго. Пргг обБнвленгггг полеи внутреннггмгг (internal) 
также могут возникнутв проблемБг, посколбку даже внутргг однои сборкгг оченв 
трудно отследитБ все обрагценгш к полим, особенно когда над неи работает не- 
сколбко разработчиков. 

□ Методвг, своиства гг собвгтгш класса и всегда о6бнвлнго закрвгтБгми гг невггрту- 
алБНБгмгг. К счастБго, C# по умолчанггго делает ггменно так. Разумеетсл, чтобкг 
типом можно 6бгло восполБЗОватБСл, некоторБге методБг, своиства гг собвгтил 
должнбг 6бгтб открБгтБгмгг, но лучше не делатБ ггх загцгггценнБгмгг гглгг внутрен- 
нггмгг, посколБку зто может сделатБ тип унзвггмБгм. Впрочем, загцгггценнБги гглгг 



Компонен™, полиморфизм и версии 205 


внутреннии член все-таки лучше виртуалБного, посколБку последнии предо- 
ставллет производному классу болБшие возможности и всецело зависит от 
корректности его поведенгш. 

□ В ООП естБ провереннБш временем принцип: «лучшии метод борвбв1 со слож- 
ностбк) — добавление hobbix типов>>. Если реализацин алгоритма чрезмерно 
усложннетсл, следует определитв вспомогателБНБге типбг, инкапсулиругогцие 
частБ функционалБности. Если вспомогателБНБге типбг исполБзуготсл в един- 
ственном супертипе, следует сделатв их вложеннБгми. Зто позволит ссБглатвсн на 
них через супертип и позволит им обрагцатвсн к загцигценнБш членам супертипа. 
Однако сугцествует правило проектировангш, примененное в утилите FxCopCmd. 
ехе Visual Studio и рекомендугогцее определнтв обгцедоступнБге вложеннБге типбг 
в области видимости фаила или сборки (за пределами супертипа), посколвку 
некоторкге разработчики считагот синтаксис обрагценич к вложеннкгм типам 
громоздким. И соблгодаго зто правило, и никогда не определиго открвгтвге вло- 
женнвге типбг. 


Работа с виртуалБНмми методами 
при управлении версивми типов 

Как уже отмечалоск, управление версгшми — важнвги аспект компонентного про- 
граммировангш. Некоторвгх проблем и коснулси в главе 3 (там речв шла о сборках 
со строгими именами и обсуждалиск мерБг, позволнгогцие администраторам гаран- 
тироватв привнзку приложенин именно к тем сборкам, с которвгми оно бвгло по- 
строено и протестировано). Однако при управлении версгшми возникагот и другие 
сложности с совместимостБго на уровне исходного кода. В частности, следует 6бгтб 
оченБ осторожнБгми пргг добавленгггг гг изменении членов базового тггпа. Рассмотрим 
несколвко примеров. 

Пуств разработчикамгг компании СотрапуА спроектирован тип Phone: 

namespace СотрапуА { 
public class Phone { 
public void Dial() { 

Console.WriteLine("Phone.Dial"); 

// Bbino/iHHTb деиствин по набору телефонного номера 

} 

} 

} 


А теперв представБте, что в компании СотрапуВ спроектировали другои тип, 
BetterPhone, исполБзугогции тип Phone в качестве базового: 

namespace СотрапуВ { 

public class BetterPhone : СотрапуА. Phone { 
public void Dial() { 

Console.WriteLine("BetterPhone.Dial"); 

EstablishConnection(); 


продолжение & 
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base.Dial(); 

} 

protected virtual void EstablishConnection() { 

Console.WriteLine("BetterPhone.EstablishConnection"); 
// Bbino/iHkiTb деиствин по набору телефонного номера 

} 

} 

} 


При попмтке скомпилироватБ свои код разработчики компании СотрапуВ полу- 
чагот от компилнтора C# предупреждение: 

warning CS0108: 'CompanyB.BetterPhone.Dial() ' hides inherited member 

'CompanyA.Phone.Dial()'. Use the new keyword if hiding 
was intended. 

Смбгсл в том, что метод Dial, определнемвш в типе BetterPhone, скроет одно- 
именнвш метод в Phone. В новои версии метода Dial его семантика может статв 
совсем инои, нежели та, что определена программистами компании СотрапуА в ис- 
ходнои версии метода. 

Предупреждение о таких потеициалБНБ1х семантических несоответствилх — 
оченв полезнан функцин компиллтора. Компилптор также подсказБ1вает, как 
избавитБСп от зтого предупрежденгш: нужно поставитп клгочевое слово new перед 
определением метода Dial в классе BetterPhone. Вот как вбшллдит исправленнБш 
класс BetterPhone: 

namespace СотрапуВ { 

public class BetterPhone : СотрапуА. Phone { 

// Зтот метод Dial никак не свлзан с одноименнмм методом класса Phone 
public new void Dial() { 

Console.WriteLine("BetterPhone.Dial"); 

EstablishConnection(); 
base.Dial(); 

} 

protected virtual void EstablishConnection() { 

Console.WriteLine("BetterPhone.EstablishConnection"); 

// Bbinon н HTb деиствил по установленит соединенил 

} 

} 

} 


ТеперБ компашш СотрапуВ может исполБЗОватБ в своем приложении тип 
BetterPhone следуклцим образом: 

public sealed class Program { 
public static void Main() { 

СотрапуВ .BetterPhone phone = new СотрапуВ .BetterPhone(); 
phone.Dial(); 

} 

} 
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При вмполнении зтого кода вмводитсн следуклцаи информацгш: 

BetterPhone.Dial 

BetterPhone.EstablishConnection 

Phone.Dial 

Резулкгат свидетелБСтвует о том, что код вБгполннет именно те деиствии, кото- 
pbie нужнћг компании СотрапуВ. При вћгзове Dial вБгзБгваетсл нован версин зтого 
метода, определеннаи в типе BetterPhone. Она сначала вБИБгвает виртуалБнвш 
метод EstablishConnection, а затем — исходнуго версшо метода Dial из базового 
типа Phone. 

А теперБ представим, что несколБКО компании решили исполћзоватБ тип Phone, 
созданнБги в компании СотрапуА. Допустим также, что все они сочли полезнБгм 
установление соединенин в самом методе Dial. Зти отзбгвбг заставили разработчиков 
компании СотрапуА усовершенствоватБ класс Phone: 

namespace СотрапуА { 
public class Phone { 
public void Dial() { 

Console.WriteLine("Phone.Dial"); 

EstablishConnection(); 

// Bbinon н итб деиствил по набору телефонного номера 

} 

protected virtual void EstablishConnection() { 

Console.WriteLine("Phone.EstablishConnection"); 

// ВиполнитБ деиствил по установленига соединенил 

} 

} 

} 

В резулБтате теперБ разработчики компании СотрапуВ при компилнции своего 
типа BetterPhone (производного от новои версии Phone) получагот следугогцее 
предупреждение: 

warning CS0114: ' BetterPhone . EstablishConnection( )' hides inherited member 

'Phone.EstablishConnection()'. To make the current member override 
that implementation, add the override keyword. Otherwise, 
add the new keyword 

B нем говоритсн o том, что ' BetterPhone . EstablishConnection( ) ' скрвшает 
унаследованш>ш член ' Phone . EstablishConnection( )', и чтобвг текугции член 
переопределил реализацшо, нужно вставитв клгочевое слово override; в противном 
случае нужно вставитв клгочевое слово new. 

То еств компилнтор предупреждает, что как Phone, так и BetterPhone предла- 
гагот метод EstablishConnection, семантика которого может отличатБСн в разнвгх 
классах. В зтом случае простал перекомпилицгш BetterPhone болБше не может 
гарантироватБ, что нован версгш метода будет работатБ так же, как прежннн, опреде- 
леннан в типе Phone. 
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Если в компании СотрапуВ решат, что семантика метода EstablishConnection 
в зтих двух типах отличаетсл, компиллтору будет указано, что <<правилвнмми>> 
ПВЛИ10ТСН методм Dial и EstablishConnection, определеннме в BetterPhone, 
и они не свизанм с одноименнмми методами из базового типа Phone. Длл зтого 
разработчики компании СотрапуВ добавлигот клгочевое слово new в определение 
EstablishConnection: 

namespace СотрапуВ { 

public class BetterPhone : СотрапуА. Phone { 

// Клтчевое слово 'new' оставлено, чтобн указати, 

// что зтот метод не свлзан с методом Dial базового типа 
public new void Dial() { 

Console.WriteLine("BettenPhone.Dial"); 

EstablishConnection(); 
base.Dial(); 

} 

// Клтчевое слово 'new' указмвает, что зтот метод 
// не свлзан с методом EstablishConnection базового типа 
protected new virtual void EstablishConnection() { 
Console.WriteLine("BetterPhone.EstablishConnection"); 

// Bbino^HHTb деиствив длл установленив соединенин 

} 

} 

} 


ЗдесБ клгочевое слово new заставлпет компиллтор сгенерироватБ метадан- 
Hbie, информиругогцие CLR, что определеннБШ в BetterPhone методБ1 Dial 
и EstablishConnection следует рассматриватБ как noisbie функции, введеннБ1е 
в зтом типе. При зтом CLR будет известно, что одноименнБ1е методБ1 типов Phone 
и BetterPhone никак не свнзанБг 

При вБшолнении того же приложенин (метода Main) вбшодитсл информацгш: 

BetterPhone.Dial 

BetterPhone.EstablishConnection 

Phone.Dial 

Phone.EstablishConnection 

Отсгода видно, что, когда Main обрагцаетсл к методу Dial, вБ 13 Б 1 ваетсн вер- 
сил, определеннал в BetterPhone. Далее Dial ввговшает виртуалБнви! ме- 
тод EstablishConnection, также определеннБ1и в BetterPhone. Когда метод 
EstablishConnection типа BetterPhone возвравдает управление, вБ 13 Б 1 ваетсл 
метод Dial типа Phone, вБШБшагогции метод EstablishConnection зтого типа. Но 
посколБку метод EstablishConnection в типе BetterPhone помечен клгочеввш 
словом new, ВБ 130 В зтого метода не считаетсл переопределением виртуалвного 
метода EstablishConnection, исходно определенного в типе Phone. В резулБтате 
метод Dial типа Phone вБИБшает метод EstablishConnection, определеннБп} в типе 
Phone, что и требовалосБ от программБк 
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ПРИМЕЧАНИЕ 

Если 6bi компиллтор по умолчанииз считал методи! переопределеничми (как С++), 
разработчики типа BetterPhone не смогли 6bi исполБЗОватБ в нем имена методов Dial 
и EstablishConnection. Веролтно, при изменении имен зтих методов негативнми зф- 
фект затронет вскз кодовукз базу, нарушап совместимоств на уровне исходного текста 
и двоичного кода. Обично такого рода измененич с далеко идупдими последствичми 
нежелателвни, особенно в средних и крупни 1 х проектах. Однако если изменение имени 
метода коснетсл лиши необходимости обновленил исходного текста, следует поити 
на зто, 4To6bi одинаковме имена методов Dial и EstablishConnection, обладакшдие 
разнои семантикои в разнмхтипах, не вводили взаблуждение других разработчиков. 

Алкгернативное решение: СотрапуВ, получив от СотрапуА новуго версиго типа 
Phone, решает, что текутцаи семантика методов Dial и EstablishConnection типа 
Phone — зто именно то, что нужно. В зтом случае в СотрапуВ полностбго удалигот 
метод Dial из типа BetterPhone. Посколмсу теперћ разработчикам СотрапуВ нужно 
указатБ компилитору, что метод EstablishConnection типа BetterPhone свизан 
с одноименнБш методом типа Phone, нужно удалитБ из его определенгш клгочевое 
слово new. Удаленич клгочевого слова недостаточно, так как компилнтор не поимет 
предназначении метода EstablishConnection типа BetterPhone. Чтобвг ввгразитБ 
намеренин нвно, разработчик из СотрапуВ должен изменитБ модификатор опреде- 
ленного в типе BetterPhone метода EstablishConnection с virtual на override. 
Код новои версии BetterPhone вбггллдит так: 

namespace СотрапуВ { 

public class BetterPhone : СотрапуА. Phone { 

// Метод Dial удален (так как он наследуетсл от базового типа) 

// ЗдесБ клтчевое слово new удаленоЈ а модификатор virtual заменен 
// на override, чтоби указатБЈ что зтот метод свлзан с методом 
// EstablishConnection из базового типа 
protected override void EstablishConnection() { 

Console.WriteLine("BetterPhone.EstablishConnection "); 

// Вуполн HTb деиствил по установлениго соединенин 

} 

} 

} 


ТеперБ то же приложение (метод Main) вбгводит следугогции резулвтат: 
Phone.Dial 

BetterPhone.EstablishConnection 

Видно, что когда Main вБгзкгвает метод Dial, вБгзвгваетсн версин зтого метода, 
определеннан в типе Phone и унаследованнан от него типом BetterPhone. Далее, 
когда метод Dial, определеннвш в типе Phone, вБгзвгвает виртуалБНБги метод 
EstablishConnection, вБгзБгваетсл одноименнвги метод типа BetterPhone, так 
как он переопределнет виртуалБНБги метод EstablishConnection, определиемБги 
типом Phone. 
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В зтои главе показано, как добавитБ к типу членн, содержашие дашше. В частности, 
mbi рассмотрим константм и полл. 


Константн 

Константа (constant) — зто идентпфикатор, значение которого никогда не ме- 
ннетсл. Значение, свизанное с именем константм, должно определлтБса во времи 
компилиции. Затем компиллтор сохранпет значение константБ 1 в метаданнмх 
модулн. Зто значит, что константБ 1 можно определлтБ толбко дли таких типов, 
которБ 1 е компиллтор считает примитивнвши. В C# следугогцие типб 1 считаготси 
примитивнБши и могут исполБЗОватБСп длл определенгш констант: Boolean, Char, 
Byte,SByte, Intl6, UIntl6, Int32, UInt32, Int64, UInt64, Single, Double, Decimal 
и Stning. Тем не менее C# позволнет определитв константнуго переменнуго, не от- 
носигцугоси к злементарному типу, если присвоитп eii значение null: 

using System; 

public sealed class SomeType { 

// Некоторме типм не нвлнвтсн злементарнмми, но C# допускает сушествование 
// константнмх переменнмх атих типов после присваиванил значенил null 
public const SomeType Empty = null; 

} 

Так как значение констант никогда не меннетсл, константБ 1 всегда считаготси 
частвго типа. Иначе говорн, константБ 1 считаготси статическими, а не зкземплир- 
нбши членами. Определение константБ 1 приводит в конечном итоге к созданиго 
метаданнБгх. 

Встретив в исходном тексте имл константБц компилнтор просматривает метадан- 
HBie модулн, в котором она определена, извлекает значение константБ1 и внедрнет 
его в генерируемБП! им IL -код. Посколкку значение константБ 1 внедриетсн прнмо в 
код, в период вБшолненин памнтБ длл констант не вБвделиетси. Кроме того, нелБЗи 
получатБ адрес константБ1 и передаватБ ее по сспшке. Зти ограниченгш также озна- 
чагот, что изменитБ значенин константБ1 в разнвш версиих модулл нелвзн, позтому 
константу надо исполпзоватБ, толбко когда точно известно, что ее значение никогда 
не изменитсн (хорошии пример — определение константБ 1 Maxlntl6 со значением 
32767). Поиснго на примере, что л имего в виду. Возвмем код и скомпилируем его 
в DLL -сборку: 
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using System; 

public sealed class SomeLibraryType { 

// ПРИМЕЧАНИЕ: C# не позволлет исполизоватн длл констант модификатор 
// static, посколнку всегда подразумеваетсл, что константн лвллитсл 
// статическими 

public const Int32 MaxEntriesInList = 50; 

} 

Затем построим сборку приложении из следуквдего кода: 

using System; 

public sealed class Program { 
public static void Main() { 

Console.WriteLine("Max entries supported in list: " 

+ SomeLibraryType.MaxEntriesInList); 

} 

} 

Нетрудно заметитћ, что код приложенип содержит ссшлку на константу 
MaxEntriesInList. При компоновке зтого кода компиллтор, обнаружив, что 
MaxEntniesInList — зто литерал константм со значением 50, внедрит значение 50 
типа Int 32 прнмо в IL -код приложенгш. Фактически после построенгш кода при- 
ложенгш DLL -сборка даже не будет загружатг>сн в период вБгполненгш, позтому ее 
можно просто удалитћ с диска. 

.method public hidebysig static void Main() cil managed 

{ 

.entrypoint 

// Code size 25 (0x19) 

.maxstack 8 
IL_0000: nop 

IL_0001: ldstr "Мах entries supported in list: " 

IL_0006: ldc.i4.s 50 

IL_0008: box [mscorlib]System.Int32 

IL_000d: call string [mscorlib]System.String::Concat(object, object) 

IL_0012: call void [mscorlib]System.Console::WriteLine(string) 

IL_0017: nop 
IL_0018: ret 

} // Закрмваем метод Program::Main 

Теперк проблема управленгш версгшми при исполБЗОвангш констант должна 
статвочевиднои. Если разработчикизменит значениеконстантвг MaxEntniesInList 
на 1000 и перестроит толбко DLL -сборку, зто не повлгшет на код самого прило- 
женгш. Длл того чтобвг в приложении исполБЗОвалосБ новое значение константвг, 
его тоже необходимо перекомпилироватБ. НелБЗн применнтБ константБг во времн 
вБгполненгш (а не во времн компилицгш), если модулв должен задеиствоватБ 
значение, определенное в другом модуле. В отом случае вместо констант следует 
исполвзоватБ предназначеннБге толбко длл чтенил полл, о которкгх речБ идет 
в следугогцем разделе. 
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Полл 

Поле (field) — зто член даннмх, которми хранит зкземплнр значимого типа или 
ссмлку на ссмлочнми тип. В табл. 7.1 приведенм модификаторм, применнемме по 
отношеншо к полим. 


Таблица 7.1 . МодификаторБ! полеи 


Термин CLR 

Термин C# 

Описание 

Static 

static 

Поле лвллетсл частБго состоннил типа, а не обвекта 

Instance 

(по умол- 
чаниго) 

Поле свлзано с зкземпллром типа, а не самим типом 

InitOnly 

readonly 

ЗаписБ в поле разрешаетсл толбко из кода конструктора 

Volatile 

volatile 

Код, обрагдагшциисл к полго, не должен оптимизироватБСл 
компилнтором, CLR или оборудованием с целвго обеспе- 
ченил безопасности потоков. НеустоичивБгми (volatile) 
могут о6блвллтбсл толбко следугогцие типбг: все ссбшоч- 
нбш типбг, Single, Boolean, Byte, SByte, Intl6, UIntl6, 

Int32, UInt32, Char, a также все перечислимвге типбг, 
основаннБге на типе Byte, SByte, Intl6, UIntl6, Int32 или 
UInt32. НеустоичивБге полн рассматриваготсл в главе 2 


Как видно из таблицм, обгцеизмковаи среда (CLR) поддерживает полл как 
типов (статические), так и зкземплнров (нестатические). Динамическаи памнтБ 
длн храненгш полн типа вмделлетсл в пределах обвекта типа, которми создаетси 
при загрузке типа в домен приложении (см. главу 22), что обмчно происходит при 
JIT -компилиции лгобого метода, ссмлагогцегоси на зтот тип. Динамическаи памлтБ 
длн храненгш зкземплнрнмх полеи вмделнетси при создании зкземплира данного 
типа. 

ПосколБку полн храпитси в динамическои памнти, их значенин можно получитБ 
лишб в период вмполненгш. Поли также решагот проблему управлении версинми, 
возникагогцуго при исполБЗОвании констант. Кроме того, полго можно назначитБ 
лгобои тип даннБгх, позтому при определении полеи можно не ограничиватБСл 
встроеннБгми злементарнБгми типами компилнтора (что приходитсл делатк при 
определении констант). 

CLR поддерживает поли, предназначеннБге длн чтении и записи (изменнемБге), 
а также полн, предназначеннБге толбко длн чтении (неизмениемБге). Болбшинство 
полеи изменнемБге. Зто значит, что во времл исполненин кода значение таких полеи 
может многократно менитвсн. ДаннБге же в неизменнемвге полн можно записБгватБ 
толбко при исполнении конструктора (которкги вБгзБгваетси лишб раз — при соз- 
дании обвекта). Компилитор и механизм верификации гарантиругот, что ни один 
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метод, кроме конструктора, не сможет записатћ даннБге в поле, предназначенное 
толбко длл чтенин. Замечу, что дли измененин такого полн можно задеиствоватБ 
отражение. 

Попробуем решитБ проблему управленил версиими в примере из раздела 
«КонстантБ 1 », исполБзун статические неизменнемБге поли. Вот новаи версгш кода 
DLL -сборки: 

using System; 

public sealed class SomeLibraryType { 

// Модификатор static необходим, чтобм поле 
// ассоциировалосБ с типом, а не зкземпллром 
public static readonly Int32 MaxEntriesInList = 50; 

} 

Зто единственное изменение, которое придетсл внести в исходнбпт текст, при 
зтом код приложенин можно вовсе не меннтв, но чтобнг увидетБ его новбш своиства, 
его придетсн перекомпилироватБ. ТеперБ при исполнении метода Main зтого при- 
ложенин CLR загружает DLL -сборку (так как она требуетсн во времн ВБШолненил) 
и извлекает значение полн MaxEntriesInList из динамическои памнти, ввгделеннои 
длн его храненгш. Естественно, зто значение равно 50. 

Допустим, разработчик сборки изменил значение полн с 50 на 1000 и скомпо- 
новал сборку заново. При повторном исполнении код приложенгш автоматически 
задеиствует новое значение — 1000. В зтом случае не обизателвно компоноватв код 
приложенгш заново, оно просто работает в том виде, в котором бвшо (хотл и чутв 
медленнее). Однако зтот сценарии предполагает, что у новои сборки нет строгого 
имени, а политика управленгш версгшми приложенгш заставлнет CLR загружатв 
именно зту новуго версиго сборки. 

В следугогцем примере показано, как определлтв изменнемБге статические поли, 
а также изменнемБге и неизменнемБге зкземплирнБге поли: 

public sealed class SomeType { 

// Статическое неизменлемое поле. Его значение рассчитмваетсд 
// и сохраннетсл в памнти при инициализации класса во времн вмполненив 
public static readonly Random s_random = new Random(); 

// Статическое изменнемое поле 
private static Int32 s_numberOfWrites = 0; 

// Неизменнемое зкземплнрное поле 
public readonly String Pathname = "Untitled"; 

// Изменнемое зкземплдрное поле 
private System.10.FileStream m_fs; 

public SomeType(String pathname) { 

// Зта строка изменвет значение неизменвемого пола 
// В данном случае зто возможно, так как показаннми далее код 
// расположен в конструкторе 


продолжение & 
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this . Pathname = pathname; 

} 

public String DoSomething() { 

// Зта строка читает и записмвает значение статического изменнемого полл 
s_numberOfWrites = s_numberOfWrites + 1; 

// Зта строка читает значение неизменнемого зкземпллрного полл 
return Pathname; 

} 

} 

Многие поли в нашем примере инициализируготси на месте (inline). C# позво- 
лиет исполБЗОватБ зтот удобнми синтаксис дли инициализации констант, а также 
измениеммх и неизмениеммх полеи. Как продемонстрировано в главе 8, C# рас- 
сматривает инициализациго полн на месте как синтаксис сокрагценнои записи, 
позволнгогции инициализироватв поле во времн исполненгш конструктора. Вместе 
с тем, в C# возможнм проблемм производителг>ности, которме нужно учитмватг. 
при исполг>зовангш синтаксиса инициализации поли на месте, а не присвоении 
в конструкторе. Они также обсуждаготсн в главе 8. 

ВНИМАНИЕ 

Неизменноств полл ссвточного типа означает неизменности ссђтки, которукз зтот 
тип содержит, а вовсе не обвекта, на которукз указмвает сситка, например: 

public sealed class АТуре { 

// InvalidChars всегда сснлаетсл на один обћект массива 

public static readonly Char[] InvalidChars = new Char[] { 'A', 'B', 'C'); 

} 

public sealed class AnotherType { 
public static void M() { 

// Следукицие строки кода вполне корректнм, компилирукзтсл 
// и успешно изменлкзт символм в массиве InvalidChars 
AType.InvalidChars[0] = 'X'; 

AType.InvalidChars[l] = 'V; 

AType.InvalidChars[2] = 'Z'; 

// Следукицал строка некорректна и не скомпилируетсл, 

// так как ссмлка InvalidChars изменлтвсл не может 
АТуре. InvalidChars = new Char[] { 'X', ' Y', 'Z' }; 

} 

} 
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В зтои главе обсуждаготсн разновидности методов, которме могут определнтБСи 
в типе, и разбираетсн рад вопросов, касагогцихсн методов. В частности, показано, как 
определнготсн методБ1-конструкторБ1 (создагогцие зкземплнрБг типов и сами типбг), 
методБ1 перегрузки операторов и методБ1 преобразованип (вБшолнпгогцие нвное гг не- 
пвное приведенгге типов). Также речв поидет о методах расширенгш, позволнгогцих 
добавлнтБ собственнБге методБг к уже сугцествугогцим типам, и частичнвгх методах, 
позволнгогцггх разделитБ реализацггго типа на несколпко частеи. 


КонструкторБ! зкземпллров и классн 
(ccbmoHHbie типн) 

КонструкторБг — зто специалБНБге методБг, позволнгогцгге корректно ггнггцггализгг- 
роватв новбпг зкземплир тггпа. В таблггце определенгги, входнгцих в метаданнвге, 
методБг-конструкторБг всегда отмечагот сочетанггем .cton (от constructor). При 
создаиии зкземплира обвекта ссбшочного типа вБгделиетси памитБ дли полеи дан- 
нбгх зкземплира и ггнггцггалггзггруготсн служебнкге поли (указателн на обвект-тип 
и ггндекс блока сггнхронизацгпг), после чего вБгзБгваетси конструктор зкземплира, 
устанавливагогции ггсходное состоингге нового обвекта. 

Пргг конструировангги обвекта ссбшочиого типа вБгделнемаи длл него памнтн 
всегда обнуллетси до ввгзова конструктора зкземплнра типа. Лгобвге no./ia, не за- 
даваемвге конструктором нвно, гарантированно содержат 0 илгг null. 

В отлггчие от других методов конструкторвг зкземпллров не наследуготсн. Иначе 
говори, у класса еств толбко те конструкторкг зкземплиров, которвге определенвг 
в зтом классе. Невозможноств наследовангш означает, что к конструктору зкзем- 
плнров нелБЗн применнтБ модггфггкаторБг vintual, new, ovennide, sealed гг abstnact. 
Еслгг определитБ класс без нвно заданнвгх конструкторов, мнопге компшшторБг (в том 
числе компилитор С#) создадут конструктор по умолчанггго (без параметров), реа- 
лггзацгш которого просто ввгзБгвает конструктор без параметров базового класса. 

Например, рассмотрим следугогцее определенгге класса: 
public class SomeType { } 

Зто определенгге идентично определенггго: 

public class SomeType { 

public SomeType() : base() { } 

} 
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Дли абстрактнмх классов компилитор создает конструктор по умолчаниго с мо- 
дификатором protected, в противном случае областБ деиствин будет открБ 1 тои 
(public). Если в базовом классе нет конструктора без параметров, производнћш 
класс должен нвно вБ13ватБ конструктор базового класса, иначе компилитор вернет 
ошибку. Дли статических классов (запечатаннБ 1 х и абстрактнБ 1 х) компилитор не 
создает конструктор по умолчаниго. 

В типе может определлтБСн несколБКО конструкторов, при зтом сигнатурБ1 
и уровни доступа к конструкторам обнзателвно должнб 1 отличдтбсн. В случае 
верифицируемого кода конструктор зкземплнров должен вБШБшатв конструктор 
базового класса до обрагценин к какому-либо из унаследованнвш от него полеи. 
Многие компилиторБ1, вклгочан С#, генериругот вб130в конструктора базового 
класса автоматически, позтому вам, как правило, об зтом можно не беспокоитвси. 
В конечном счете всегда ввгоБшаетсн открБ1ТБ1и конструктор обвекта System . Ob ject 
без параметров. Зтот конструктор ничего не делает — просто возврагцает управление 
по тои npocToii причине, что в Sy stem . Ob ject не определено никаких зкземплнрнвгх 
полеи даннБгх, позтому конструктору просто нечего делатк. 

В редких ситуацгшх зкземплир типа может создаватнси без вБгзова конструк- 
тора зкземплнров. В частности, метод MemberwiseClone обвекта Object ввгделлет 
памитБ, инициализирует служебнБге полн обвекта, а затем копирует баитнг ис- 
ходного обвекта в областв памнти, вБгделеннуго длл нового обвекта. Кроме того, 
конструктор обвгчно не вБ 13 Бшаетси при десериализации обвекта. Код десериа- 
лизации вБгделиет памитБ длл обвекта без вБгзова конструктора, исполвзуи метод 
GetUninitializedObject или GetSafeUninitializedObject типа System . Runtime . 
Serialization . FormatterServices (см. главу 24 ). 

ВНИМАНИЕ 

НелБза Bbi3biBaTb какие-либо виртуалБНБ 1 е методБ! конструктора, которме могут 
повличтб на создаваемБ 1 и обвект. Причина проста: если вБ13мваемми виртуалБнми 
метод переопределен в типе, зкземплчр которого создаетсч, происходит реализа- 
циа производного типа, но к зтому моменту еше не завершиласБ инициализацич 
всех полеи в иерархии. В таких обсточтелБСтвах последствич вБ130ва виртуалБного 
метода непредсказуемм. 


C# предлагает простои синтаксис, позволигогции инициализироватБ поли во 
времи созданин обвекта ссбшочного типа: 

internal sealed class SomeType { 
private Int32 m_x = 5; 

} 

При создангш обвекта SomeType его поле m_x инициализируетсн значением 5. 
Вбг можете спроситБ: как зто происходит? Изучив IL -код метода-конструктора 
зтого оОЂекта (зтот метод также фигурирует под именем . ctor), вбг увидите сле- 
дугогции код: 
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.method public hidebysig specialname rtspecialname 
instance void .ctor() cil managed 

{ 

// Code size 14 (0xe) 

.maxstacl< 8 
IL_0000: ldarg.0 
IL_0001: ldc.i4.5 

IL_0002: stfld int32 SomeType::m_x 
IL_0007: ldarg.0 

IL_0008: call instance void [mscorlib]System.Object::.ctor() 

IL_000d: ret 

} // end of method SomeType::.ctor 

Как видите, конструктор обљскта SomeType содержит код, записмваклции в поле 
m_x значение 5 и вмзмваговдии конструктор базового класса. Иначе говорн, компи- 
лнтор C# предлагает удобнми синтаксис, позволнгогции инициализироватБ поли 
зкземплнра при их обљин.тепии. Компилитор транслирует зтот синтаксис в метод- 
конструктор, вмполнчгогции инициализациго. Зто значит, что нужно 6мтб готовбш 
к разрастаниго кода, как зто показано на следугогцем примере: 

internal sealed class SomeType { 
private Int32 m_x = 5; 
private String m_s = "Hi there"; 
private Double m_d = 3.14159; 
private Byte m_b; 

// Зто конструкторн 

public SomeType() { ... } 

public SomeType(Int32 х) { ... } 

public SomeType(String s) { ...; m_d = 10; } 

} 


Генерирун IL -код длл трех методов-конструкторов из зтого примера, компиллтор 
помегцает в начало каждого из методов код, инициализиругогции полн m_x, m_s и m_d. 
После кода инициализации вставлиетсл вбгоов конструктора базового класса, а за- 
тем добавлиетси код, расположеннБш внутри методов-конструкторов. Например, 
IL -код, сгенерированнБш дли конструктора с параметром типа String, состоит из 
кода, инициализиругогцего полн m_x, m_s и m_d, и кода, перезаписБшагогцего поле m_d 
значением 10. ЗаметБте: поле m_b гарантированно инициализируетсл значением 0, 
даже если нет кода, инициализиругогцего зто поле ивно. 

ПРИМЕЧАНИЕ 

Компилатор инициализирует все пола при помо^ци соответствук)ш,его синтаксиса 
перед вб130вом конструктора базового класса длл поддержаниа представленил 
о том, что все полл имекзт rappeKTHbie значенип, обозначенние в исходном коде. По- 
тенциалиназ проблема может возникнуљ в тех случалх, когда конструктор базового 
класса Bbi3biBaeT виртуалвнми метод, осу|дествликхции o6paTHbiti внзов в метод, 
определеннни в производном классе. В зтом случае полз инициализирукггса при 
помшци соответствукицего синтаксиса перед внзовом виртуалвного метода. 
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ПосколБку в показанном ранее классе определенм три конструктора, компилн- 
тор триждм генерирует код, инициализиругогции полн m_x, m_s и m_d: по одному 
разу дли каждого из конструкторов. Если имеетсл несколгжо инициализируеммх 
зкземплнрнмх полеи и множество перегруженнмх методов-конструкторов, стоит 
подуматБ о том, что6б1 определитБ полн без инициализации; создатн единственнБпг 
конструктор, вбшолннгогции обгцуго инициализациго, и заставитн каждБш метод- 
конструктор нвно вБгзБгватБ конструктор, вБшолннгогции обгцуго инициализациго. 
Зтот подход позволит уменвшитБ размер генерируемого кода. Следугогции пример 
иллгострирует исполБЗОвание способности C# нвно заставлитв один конструктор 
ББгзБшатБ другои конструктор посредством зарезервированного слова this: 

internal sealed class SomeType { 

// ЗдесБ нет кода, пвно инициализирукицего полн 

private Int32 m_x; 

private String m_s; 

private Double m_d; 

private Byte m_b; 

// Код зтого конструктора инициализирует поли значенилми по умолчаник) 

// Зтот конструктор должен вмзмватцсн всеми осталцнмми конструкторами 
public SomeType() { 
m_x = 5; 

m_s = "Hi there"; 
m_d = 3.14159; 
m_b = 0xff; 

} 

// Зтот конструктор инициализирует полв значенипми по умолчаникз, 

// а затем изменвет значение m_x 
public SomeType(Int32 х) : this() { 
m_x = х; 

} 

// Зтот конструктор инициализирует полв значенилми по умолчаникз, 

// а затем изменпет значение m_s 
public SomeType(String s) : this() { 
m_s = s; 

} 

// Зтот конструктор инициализирует полв значенипми по умолчаникз, 

// а затем изменвет значенип m_x и m_s 
public SomeType(Int32 х, String s) : this() { 
m_x = х; 
m_s = s; 

} 

} 
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Конструкторн зкземпллров и структурм 
(значимме типм) 

Конструкторм значиммхтипов (struct) работакзт иначе, чемссмлочнмх (class). 
CLR всегда разрешает создание зкземплиров значиммх типов и зтому ничто не 
может помешатБ. Позтому, по болБшому счету, конструкторм у значимого типа 
можно не определлтБ. Фактически многие компилиторБ 1 (вклгочаи С#) не опреде- 
лнгот длл значимБ1Х типов конструкторв1 по умолчаншо, не имегогцие параметров. 
Разберем следугошии код: 

internal struct Point { 
public Int32 m_x, m_y; 

} 

internal sealed class Rectangle { 

public Point m_topLeft, m_bottomRight; 

} 

Длл того что 6 б 1 создатв обвект Rectangle, надо исполБЗОватБ оператор new 
с указанием конструктора. В зтом случае вБИБшаетсл конструктор, автоматически 
сгенерированнБ 1 и компилитором С#. ПамнтБ, вБвделеннан дли обвекта Rectangle, 
вклгочает место длн двух зкземплнров значимого типа Point. Из соображении по- 
вБшенгш производителБности CLR не пБТгаетсл вБГОватБ конструктор длн каждого 
зкземплира значимого типа, содержагцегоси в обвекте ссбшочного типа. Однако, 
как отмечалосБ ранее, поли значимого типа инициализируготси пулмми /null. 

Вообгце говорн, CLR позволнет программистам определнтв конструкторБг длл 
значимБгх типов, но зти конструкторвг ВБ1 ПОЛННГОТСН лишб при наличии кода, нвно 
вБГОБшагогцего один из них, например, как в конструкторе обвекта Rectangle: 

internal struct Point { 
public Int32 m_x, m_y; 

public Point(Int32 х, Int32 у) { 
m_x = х; 

m_y = у; 

} 

} 

internal sealed class Rectangle { 

public Point m_topLeft, m_bottomRight; 

public Rectangle() { 

// B C# оператор new, исполБЗОваннми длл созданил зкземпллра значимого 
// типа, BbBNBaeT конструктор длл инициализации полеи значимого типа 
m_topLeft = new Point(l, 2); 
m_bottomRight = new Point(100, 200); 

} 

} 
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Конструктор зкземплира значимого типа вмполннетсл толбко при нвном вм- 
зове. Так что если конструктор обвекта Rectangle не инициализировал его полн 
m_topLeft и m_bottomRight вмзовом с помошмо оператора new конструктора Point, 
полн m_x и m_y у обеих структур Point будут содержатБ 0. 

Если значимБш тип Point уже определен, то определлетсн конструктор, по 
умолчаншо не имегогции параметров. Однако даваите перепишем наш код: 

internal struct Point { 
public Int32 m_Xj m_y; 

public Point() { 
m_x = m_y = 5; 

} 

} 

internal sealed class Rectangle { 

public Point m_topLeftj m_bottomRight; 

public Rectangle() { 

} 

} 

A теперв ответБте, какими значенгшми — 0 или 5 — будут инициализированБг 
поли m_x и m_y, принадлежагцие структурам Point (m_topLeft и m_bottomRight)? 
Предупреждаго, вопрос с подвохом. 

Многие разработчики (особенно с опбгтом программированин на С++) решат, что 
компилнтор C# поместит в конструктор Rectangle код, автоматически вБгзвшагогции 
конструктор структурБг Point по умолчаниго, не имегогции параметров, длн двух 
полеи Rectangle. Однако, чтобвг повбгситб бБгстродеиствие приложенгш во времн 
вБгполненгш, компилнтор C# не сгенерирует такои код автоматически. Фактически 
болБшинство компилиторов никогда не генерирует автоматически код длн ввгзова 
конструктора по умолчаниго длл значимого типа даже при наличии конструктора 
без параметров. Чтобвг принудителвно исполнитб конструктор значимого типа без 
параметров, разработчик должен добавитв код его нвного ввгзова. 

С учетом сказанного можно ожидатв, что поли m_x и m_y обеих структур Point 
из обвекта Rectangle в показанном коде будут инициализированБг нулевБгми зна- 
ченгшми, так как в зтои программе нет нвного ввгзова конструктора Point. 

Но 'а же предупредил, что мои перввги вопрос 6 бш с подвохом. Подвох в том, 
что C# не позволлет определнтв длл значимого типа конструкторнг без параметров. 
Позтому показаннБпг код на самом деле даже не компилггруетсл. Пргг попкгтке ском- 
пгглггроватБ его компгглитор C# генерггрует сообгценгге об ошггбке (ошггбка CS0568: 
структура не может содержатк нвнБге конструкторБг без параметров): 

error CS0568: Structs cannot contain explicit parameterless constructors 

C# преднамеренно запрегцает определнтв конструкторвг без параметров у зна- 
чггмбгх типов, чтобвг не вводитб разработчггков в заблужденгге относителвно того, 
какои конструктор вБгзБгваетсн. Еслгг конструктор определитв нелБЗн, компгглнтор 
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никогда не будет автоматически генерироватБ код, вмзмвагогции такои конструктор. 
В отсутствие конструктора без параметров полн значимого типа всегда инициали- 
зируготсн нулнми /null. 

ПРИМЕЧАНИЕ 

В полл значимого типа облзателвно занослтсл значенил 0 или null, если значимми 
тип вложен в обвект ссмлочного типа. Однако гарантии, что полл значими 1 х типов, 
работанзидие со стеком, будут инициализированм значенилми 0 или null, нет. 4To6bi 
кодбиш верифицируемим, передчтением лнзбого полл значимоготипа, работакзидего 
со стеком, нужно записати в него значение. Если код сможет прочитатБ значение 
полл значимого типа до того, кактуда будет записано какое-то значение, может на- 
рушитисн безопасностш C# и другие компил^торм, генерирунзидие верифицируемми 
код, гарантирунзт, что полл uK)6bix значиммх типов, работаккцие со стеком, перед 
чтением обнуллнотсл или хотл бм в нихзаписмвакотсл некоторме значенил. Позтому 
при верификации во времл вмполненил исклночение вмдано не будет. Однако оби 1 чно 
можно предполагаљ, что полл значиммхтипов инициализирукотсл нулевмми значе- 
нилми, а все сказанное в зтом примечании можно полноствко игнорироватв. 


Хоти C# не допускает исполБЗОвании значиммх типов с конструкторами без 
параметров, зто допускает CLR. Так что если вас не беспоконт упомннутме скрмтме 
особенности работм системм, можно на другом лзнкс (например, на IL) определитБ 
собственнми значимми тип с конструктором без параметров. 

ПосколБку C# не допускает испо. њзонашш значиммх типов с конструктора- 
ми без параметров, при компилнции следугогцего типа компилитор сообгцает об 
ошибке: (ошибка CS0573: ' SomeValType . m_x ': не./њзл создаватБ инициализаторм 
зкземплирнмх полеи в структурах): 

еггог CS0573: 'SomeValType.m_x' : cannot have instance field initializers in structs 
A вот как вмглндит код, вмзвавшии зту ошибку: 
internal struct SomeValType { 

// В значимни тип нелвзл подставллтн инициализацин) зкземпллрнмх полеи 
private Int32 m_x = 5; 

} 

Кроме того, посколгзку верифицируемми код перед чтением лгобого полн зна- 
чимого типа требует записмватБ в него какое-либо значение, лгобои конструктор, 
определеннБш дли значимого типа, должен инициализироватБ все поли зтого типа. 
Следугогции тип определнет конструктор длл значимого типа, но не может иници- 
ализироватБ все его полн: 

internal struct SomeValType { 
private Int32 т_х л m_y; 

// C# допускает наличие у значимих типов конструкторов с параметрами 
public SomeValType(Int32 х) { 
m_x = х; 


продолжение & 
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// Обратите внимание: поле m_y здеси не инициализируетсл 

} 

} 

При компилнции зтого типа компилитор C# генерирует сообгцение об ошибке: 
(ошибка CS017 1: поле ' SomeValType . m_y 1 должно 6бггб полностбјо определено до 
возврагценин управленгш конструктором): 

error CS0171: Field 'SomeValType.m_y' must be fully assigned before control leaves 
the constructor 

Чтобвг разрешитБ проблему, конструктор должен ввести в поле у какое-нибудв 
значение (обншно 0). 

В качестве алвтернативного варианта можно инициализироватв все поли зна- 
чимого типа, как зто сделано здесв: 

// C# позволлет значимум типам иметц конструктори с параметрами 
public SomeValType(Int32 х) { 

// Bbi глвдит HeočbiHHOj но компилируетсв прекрасно, 

// и все полл инициализирукзтсл значенилми 0 или null 
this = new SomeValType( ); 

m_x = х; // Присваивает m_x значение х 

// Обратите внимание, что поле m_y бмло инициализировано нулем 

} 


В конструкторе значимого типа this представллет зкземплнр значимого типа 
и ему можно приписатв значение нового зкземплнра значимого типа, у которого 
все по.ти инициализированБ1 нулими. В конструкторах ссбшочного типа указателн 
this считаетсл доступнБтм толбко длн чтенгш и присваиватБ ему значение пе.њзи. 


Конструкторн типов 

Помимо конструкторов зкземплнров, CLR поддерживает конструкторвг типов (так- 
же известнБге как статические конструкторм, конструктори классов и инициали- 
затори типов ). Конструкторкг типов можно применнтв и к интерфеисам (хотл C# 
зтого не допускает), ссбглочнбгм и значимБгм типам. Подобно тому, как конструкторкг 
зкземплнров исполвзуготсл дли установки первоначалвного состоннии зкземплн- 
ра типа, конструкторБг типов служат длл установки первоначалвного состоинин 
типа. По умолчаниго у типа не определено конструктора. У типа не может 6бгтб 
более одного конструктора; кроме того, у конструкторов типов никогда не бвгвает 
параметров. Вот как определнготси ссвглочнвге и значимБге типбг с конструкторами 
в программах на С#: 

internal sealed class SomeRefType { 
static SomeRefType() { 

// Исполнлетсл при первом обрашении к ссмлочному типу SomeRefType 

} 
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} 

internal struct SomeValType { 

// C# на самом деле допускает определптн длп значиммх типов 
// конструкторн без параметров 
static SomeValType() { 

// Исполнлетсл при первом обрадении к значимому типу SomeValType 

} 

} 

Обратите внимание, что конструкторм типов определигот так же, как кон- 
структорм зкземплиров без параметров за исклгочением того, что их помечагот как 
статические. Кроме того, конструкторм типов всегда должнм бљпт, закрмтмми (C# 
делает их закрмтмми автоматически). Однако если нвно пометитБ в исходном тексте 
программм конструктор типа как закрмтми (или как-то иначе), компилитор C# 
вмведетсообшениеоб ошибке: (ошибка CS0515: ' SomeValType.Some-ValType() ': 
в статических конструкторах нелБЗи исполћзоватБ модификаторБ1 доступа): 

error CS0515: 'SomeValType.SomeValType() ': access modifiers are not allowed on 
static constructors 

КонструкторБ1 типов всегда должнб1 6 б1тб закрБ1ТБ1ми, что6б1 код разработчика 
не смог их вБИватБ, напротив, в то же времн среда CLR всегда способна вБ13ватБ 
конструктор типа. 

ВНИМАНИЕ 

Хота конструктор типа можно определитБ в значимом типе, зтого никогда не следует 
делатБ, так как иногда CLR не вБ13мвает статическии конструктор значимого типа. 

Например: 

internal struct SomeValType { 
static SomeValTypeQ { 

Console.WriteLine("This never gets displayed"); 

} 

public Int32 m_x; 

} 

public sealed class Program { 
public static void Main() { 

SomeValType[] a = new SomeValType[10]; 
a[0].m_x = 123; 

Console.WriteLine(a[0].m_x); // Внводитсл 123 

} 

} 

У вБгзова конструктора типа еств некоторБ 1 е особенности. При компилнции 
метода JIT -компилитор обнаруживает типб 1 , на которнш естБ ссбшки из кода. 
Если в каком-либо из типов определен конструктор, JIT -компилитор провериет, 
6 бш ли исполнен конструктор типа в данном домене приложении. Если нет, JIT- 
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компилитор создает в IL -коде вмзов конструктора типа. Если же код уже испол- 
нилсп, JIT -компилитор вмзова конструктора типа не создает, так как «знает», что 
тип уже инициализирован. 

Затем, после JI Т-компилнции метода, начинаетсн вмполнение потока, и в конеч- 
ном итоге очередБ доходит до кода вБ130ва конструктора типа. В реалБности может 
оказатБСи, что несколБКО потоков одновременно начнут вбшолнитб метод. CLR 
стараетсн гарантироватБ, что6б1 конструктор типа вбшолннлсн толбко раз в каждом 
домене приложении. Длн зтого при ввиове конструктора типа вБИБшагогции поток 
в рамках синхронизации потоков получает исклкзчакзгцуго блокировку. Зто означа- 
ет, что если несколвко потоков одновременно попБгтаготсн вБгзБшатБ конструктор 
типа, толбко один получит такуго возможностб, а осталБНБге блокируготсл. ПервБпг 
поток вбшолнит код статического конструктора. После внгхода из конструктора 
первого потока «проснутсн» простаивагогцие потоки и проверлт, 6 бш ли вБшолнен 
конструктор. Они не станут снова вбшолнитб код, а просто вернут управление из 
метода конструктора. Кроме того, при последугогцем ввгзове какого-либо из зтих 
методов CLR будет «в курсе», что конструктор типа уже вбшолннлси, и не будет 
ББгзБшатБ его снова. 

ПРИМЕЧАНИЕ 

Посколбку CLR гарантирует, что конструктор типа вБтолнлетсн толбко однаждБ! 
в каждом домене приложении, а также обеспечивает его безопасностБ по отноше- 
ник) к потокам, конструктор типа лучше всего подходит длл инициализации всех 
обвектов-одиночек (singleton), необходиммх длч су|цествованич типа. 


В рамках одного потока возможна неприитнал ситуации, когда сугцествует два 
конструктора типа, содержагцих перекрестно ссБшагогцииси код. Например, кон- 
структор типа ClassA содержит код, ссБшагогциисн на ClassB, а последнии содержит 
конструктор типа, ссБшагогциисн на ClassA. Даже в таких условгшх CLR заботитсн, 
чтобвг код конструкторов типов вБшолнилсн лигнб однаждБг, но исполнчгогцан среда 
не в состоннии обеспечитв завершение исполненгш конструктора типа ClassA до 
начала исполненгш конструктора типа ClassB. При написании кода следует избе- 
гатв подобнБгх ситуации. В деиствителБности, посколнку за вбгзов конструкторов 
типов отвечает CLR, не нужно писатв код, которми требует вкгзова конструкторов 
типов в определенном порндке. 

Наконец, если конструктор тнпа генерирует необрабатвшаемое исклгочение, CLR 
считает такои тип непригоднБш. При попБгтке обрагценгш к лгобому полго или методу 
такого типа возникает исклгочение System . TypeInitializationException. 

Код конструктора типа может обрагцатвсн толбко к статическим полнм типа; 
обнгчно зто делаетсн, чтобнг их инициализироватБ. Как и в случае зкземплирнБгх 
полеи, C# предлагает простои синтаксис: 

internal sealed class SomeType { 
private static Int32 s_x = 5; 

} 
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ПРИМЕЧАНИЕ 

C# не позволнет в значимнх типах исполвзовати синтаксис инициализации полеи 
на месте, но разрешаетзто в статических поллх. Иначе говори, если в приведенном 
ранее коде заменити class на struct, код откомпилируетсл и будет работатв, как за- 
думано. 


При компоновке зтого кода компилнтор автоматически генерирует конструктор 
типа SomeType. Иначе говори, получаетсл тот же зффект, как если бм зтот код бмл 
написан следугогцим образом: 

internal sealed class SomeType { 
private static Int32 s_x; 
static SomeType() { s_x = 5; } 

} 


При помогци утилитм ILDasm.exe нетрудно проверитБ, какои код на самом деле 
сгенерировал компилнтор. Длн отого нужно изучитБ IL -код конструктора типа. 
В таблице определении методов, составлнгогцеи метаданнћге модули, метод-кон- 
структор типа всегда назБгваетсн . cctor (от class constructor). 

Из представленного далее IL -кода видно, что метод . cctor ивлнетсл закрБгтБгм 
и статическим. Заметкте также, что код зтого метода деиствителБно записБгвает 
в статическое поле s_x значение 5. 

.method private hidebysig specialname rtspecialname static 
void .cctor() cil managed 
{ 

// Code size 7 (0x7) 

.maxstacl< 8 
IL_0000: ldc.i4.5 

IL_0001: stsfld int32 SomeType::s_x 
IL_0006: ret 

} // end of method SomeType::.cctor 

Конструктор типа не должен вБгзвшатБ конструктор базового класса. Зтот вбгзов 
не обизателен, так как ни одно статическое поле типа не испо. њзустсм совместно 
с базоввш типом и не наследуетсн от него. 

ПРИМЕЧАНИЕ 

В рлдечзБ 1 ков, такихкак Java, предполагаетсл, что при обраш,ении ктипу будетвшван 
его конструктор, а также конструктори всех его базовБ 1 хтипов. Кроме того, интер- 
феисм, реализованнме зтими типами, тоже должнм вБ13мватБ свои конструкторм. 
CLR не поддерживает такукз семантику, но позволлет компиллторам и разработчикам 
предоставллтБ поддержку подобнои семантики через метод RunClassConstructor, 
предоставллемБш типом System.Runtime.CompilerServices.RuntimeHelpers. Компи- 
ллтор лнзбого лзмка, требукдцего подобнукз семантику, генерирует в конструкторе 
типа код, Bbi3biBaiOLunH зтот метод длл всех базовмх типов. При исполвзовании 
метода RunClassConstructor длл вмзова конструктора типа CLR определлет, 6bm ли 
он исполнен ранее, и если да, то не вмзмвает его снова. 
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В завершение зтого раздела рассмотрим следукнции код: 

internal sealed class SomeType { 
private static Int32 s_x = 5; 

static SomeTypeQ { 
s_x = 10; 

} 

} 


ЗдесБ компилнтор C# генерирует единственнвш метод-конструктор типа, 
KOTopbifi сначала инициализирует поле s_x значением 5, затем — значением 10. 
Иначе говори, при генерации IL -кода конструктора типа компиллтор C# сначала 
генерирует код, инициализируклции статические поли, затем обрабатБ1вает ивнбп! 
код, содержагциисн внутри метода-конструктора типа. 

ВНИМАНИЕ 

Иногда разработчики спрашивакзт мена: можно ли исполнитб код во времл вмгрузки 
типа? Во-первмх, следуетзнатц что типб 1 вБ 1 гружакзтсл толбко при закрмтии домена 
приложении. Когда домен приложении закрмваетсл, обвект, идентифицирукхции тип, 
становитсл недоступнмм, иуборидикмусора освобождаетзанлтукз им памнљ. Многим 
разработчикам такои сценарии дает основание полагатБ, что можно добавитБ к типу 
статическии метод Finalize, автоматически вмзмваемБ 1 и при вмгрузке типа. Увм, CLR 
не поддерживает статические методБ! Finalize. Однако не все потернно: если при за- 
крмтии домена приложении нужно исполнитб некоторБ 1 и код, можно зарегистрироватБ 
метод обратного вмзова длн собмтин Domainllnload типа System.AppDomain. 


МетодБ! перегруженннх операторов 

В некоторБгх лзБ1ках тип может определнтБ, как операторБ1 должнб 1 манипулироватБ 
его зкземплнрами. В частности, многие типб 1 (например, System.Stning, System. 
Decimal и System.DateTime) исполБзугот перегрузку операторов равенства (==) 
и неравенства (! =). CLR ничего не известно о перегрузке операторов — ведБ среда 
даже не знает, что такое оператор. Смбкл операторов и код, которБш должен 6 б1тб 
сгенерирован, когда тот или инои оператор встретитси в исходном тексте, опреде- 
лнетси НЗБ1КОМ программированин. 

Например, если в программе на C# поставитБ между о6б1чнбши числами опе- 
ратор +, компилнтор генерирует код, вбшолннгогции сложение двух чисел. Когда 
оператор + применнгот к строкам, компилнтор C# генерирует код, вбшолннгогции 
конкатенациго зтих строк. Длн обозначенин неравенства в C# исполБзуетси опера- 
тор ! =, а в Visual Basic — оператор <>. Наконец, оператор л в C# задает операциго 
<<исклгочагогцее или» (XOR), тогда как в Visual Basic зто возведение в степенБ. 

Хотл CLR ничего не знает об операторах, среда указБшает, как избши програм- 
мированин должнб! предоставлнтБ доступ к перегруженнБш операторам, что6б1 
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последние могли легко иеполБЗОватБСн в коде на разнмх нзмках программированин. 
Дли каждого конкретного нзмка проектировгцики решагот, будет ли зтот нзмк под- 
держиватБ перегрузку операторов и, если да, какои синтаксис задеиствоватБ длн 
представленин и исполБЗОвангш перегруженнмх операторов. С точки зренгш CLR 
перегруженнме операторм представлигот собои просто методм. 

От вмбора нзмка зависит наличие поддержки перегруженнмх операторов и их 
синтаксис, а при компилпцгш исходного текста компиллтор генерирует метод, 
определигогции работу оператора. Спецификацил CLR требует, чтобм перегру- 
женнме операторнме методм бмли открмтмми и статическими. Дополнителг>но 
C# (и многие другие нзмки) требует, чтобм у операторного метода тип, по краинеи 
мере, одного из параметров или возврагцаемого значенгш совпадал с типом, в ко- 
тором определен операторнми метод. Причина зтого ограниченгш в том, что оно 
позволнет компилнтору C# в разумное времн находитг> кандидатурћг операторнБгх 
методов длл привнзки. 

Пример метода перегруженного оператора, заданного в определенгш класса С#: 
public sealed class Complex { 

public static Complex operator+(Complex cl, Complex c2) { ... } 

} 

Компилитор генерирует определение метода op_Addition и устанавливает в за- 
писи с определением зтого метода флаг specialname, свидетелБСтвугогции о том, что 
зто «осо6бги» метод. Когда компилнтор изкгка (в том числе компшштор С#) видит 
в исходном тексте оператор +, он исследует типбг его операндов. При зтом компи- 
литор пвгтаетсл вбшснитб, не определен ли д.;ш одного из них метод op_Addition 
с флагом specialname, параметрнг которого совместимБг с типами операндов. Если 
такои метод сугцествует, компилнтор генерирует код, вБгзБшагогции зтот метод, 
иначе возникает ошибка компилнцгш. 

В табл. 8.1 и 8.2 приведен набор унарнвгх и бинарнБгх операторов, которвге C# 
позволлет перегружатв, их обозначенгш н рекомендованнБге нмена соответствугогцих 
методов, которвге должен генерироватв компилитор. Третии столбец л прокоммен- 
тируго в следугогцем разделе. 


Таблица 8.1 . Унарнне операторБ! C# и СиЗ-совместимне имена 
соответствукнцих методов 


Оператор C# 

Ими специалБного метода 

Рекомендуемое CLS -совместимое 
има метода 

+ 

op_UnaryPlus 

Plus 

- 

op_UnaryNegation 

Negate 

I 

opLogicalNot 

Not 

- 

op_Ones Complement 

OnesComplement 


продолжение # 
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Таблица8.1 ( продолжение ) 


Оператор C# 

Ими специалБного метода 

Рекомендуемое CLS -совместимое 
имл метода 

+ + 

op^Increment 

Increment 

- 

opDecrement 

Decrement 

Нет 

opTrue 

IsTrue {get;} 

Нет 

op_False 

IsFalse {get;} 


Таблица 8.2. Бинарнне операторБ! и их CLS-coBMecTHMbie имена методов 


Оператор C# 

Имл специалБного метода 

Рекомендуемое CLS -совместимое 
имл метода 

+ 

op_Addition 

Add 

- 

op_Subtraction 

Subtract 

* 

op_Multiply 

Multiply 

/ 

opDivision 

Divide 

% 

op_Modulus 

Mod 

& 

op_BitwiseAnd 

BitwiseAnd 

1 

op_BitwiseOr 

BitwiseOr 

A 

°p_ExclusiveOr 

Хог 

« 

op_LeftShift 

LeftShift 

» 

opRightShift 

RightShift 

— 

op_Equality 

Equals 

1= 

op_Inequality 

Equals 

< 

op_LessThan 

Compare 

> 

op_GreaterT han 

Compare 

< = 

op_LessThanOrEqual 

Compare 

> = 

op_GreaterThanOrEqual 

Compare 


В спецификации CLR определенм многие другие операторм, поддаклциесн пере- 
грузке, но C# их не поддерживает. Они не очеш> распространенм, позтому и их здесБ 
не указал. Полнми список естБ в спецификации ЕСМА (www.ecma-international.org/ 
publications/standards/Ecma-335.htm) обшензмковои инфраструктурм CLI, разделм 
10.3.1 (унарнме операторм) и 10.3.2 (бинарнме операторм). 
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ПРИМЕЧАНИЕ 

Если изучиљ фундаменталвнв 1 е Tnnbi библиотеки классов .NET Framework (FCL) — 
Int32, Int64, Ulnt32 ит.д., — можно заметитБ, что они не определлнзт методв! пере- 
груженни 1 х операторов. Дело в том, что компиллторн целенаправленно игцут опе- 
рации с зтими примитивнв 1 ми типами и генерирукзт IL -командм, манипулирукзидие 
зкземпллрами зтихтипов. Если 6bi зти типм поддерживали соответствукзш,ие методн, 
а компилнтори генерировали Bbi3biBaiOLUMn их код, то каждми такои внзов снижал бм 
би 1 Стродеиствие во времн виполненил. Крометого, 4to6n реализоватв ожидаемое 
деиствие, такои метод в конечном итоге все равно исполнлл бм те же инструкции 
лзнка IL. Длл вас зто означает следукддее: если лзнк, на котором вм пишете, не 
поддерживает какои-либо из фундаменталинмхтипов FCL, вм не сможете вмполнлљ 
деиствич над зкземпллрами зтого типа. 


Операторм и взаимодеиствие взмков программированив 

Перегрузка операторов оченв полезна, посколбку позволнет разработчикам 
лаконично ввдражатБ свои мбдсли в компактном коде. Однако не все нзбдки под- 
держивагот перегрузку операторов; например, при исполБЗОвании нзвдка, не под- 
держивагогцего перегрузку, он не будет знатв, как интерпретироватБ оператор + 
(если толбко соответствугогции тип не ивлиетси злементарнБш в зтом изБдке), 
и компилитор сгенерирует ошибку. При исполБЗОвании избдков, не поддержи- 
вагогцих перегрузку, нзбгк должен позволитб вбгзбгвцтб методБг с приставкои ор_ 
(например, op_Addition) напрпмуго. 

Если вб1 пишете на изБгке, не поддерживагогцем перегрузку оператора + путем 
определенин в типе, ничто не мешает типу предоставитв метод op_Addition. Логично 
ожидатБ, что в C# можно ввгзватБ зтот метод op_Addition, указав оператор +, но зто 
не так. Обнаружив оператор +, компшштор C# шцет метод op_Addition с флагом 
метаданнБгх specialname, которБпг информирует компиллтор, что op_Addition — 
зто перегруженнБги операторнБги метод. А посколбку метод op_Addition создан на 
изБгке, не поддерживагогцем перегрузку, в методе флага specialname не будет, 
и компилнтор C# вернет ошибку. ilcno, что код лгобого нзвгка может нвно вБгзвшатБ 
метод по имени op_Addition, но компшшторБг не преобразугот оператор + в вбгзов 
отого метода. 


Особое мнение автора о правилах Microsoft, сввзаннмх 
с именами методов операторов 

Л уверен, что все зти правила, касагогциесн случаев, когда можно или нелвзи вбг- 
зватБ метод перегруженного оператора, излишне сложнбг. Если 6бг компилиторБг, 
поддерживагогцие перегрузку операторов, просто не генерировали флаг метаданнвгх 
specialname, можно 6 бгло 6бг заметно упроститн зти правила, и программистам стало 
6 bi намного легче работатн с типами, поддерживагогцими методвг перегруженнБгх 
операторов. Если 6 бг лзбгки, поддерживагогцие перегрузку операторов, поддерживали 
6 бг и синтаксис операторов, все лзбиси также поддерживали 6 бг лвнбги вбгзов методов 
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с приставкои ор_. Л не могу назватБ ни однои причинБ 1 , заставившеи Microsoft так 
усложнитв зти правила, и надегосв, что в следугогцих версиих своих компилиторов 
Microsoft упростит их. 

Дли типа с методами перегруженнБ 1 х операторов Microsoft также рекомендует 
определнтв открБ1ТБ1е зкземплнрнБге методБ1 с дружественнБши именами, ВБ13Б1- 
вагогцие методвг перегруженнБгх операторов в своеи внутреннеи реализации. На- 
пример, тип с перегруженнвши методами op_Addition или op_AdditionAssignment 
должен также определнтБ открбгтбги метод с дружественнБш именем Add. Список 
рекомендованнБгх дружественнБгх имен длл всех методов операторов приводитси 
в третвем столбце табл. 8.1 и 8.2. Таким образом, показаннБш ранее тип Complex 
можно 6б1ло 6б1 определитБ и так: 

public sealed class Complex { 

public static Complex operator+(Complex clj Complex c2) { ... } 
public static Complex Add(Complex cl, Complex c2) { return(cl + c2); } 

} 

ilcno, что код, написаннБш на лгобом чзБгке, способен вБгзкшатБ лгобои из опера- 
торнБгх методов по его дружественному имени, скажем Add. Правила же Microsoft, 
предписвшагогцие дополнителБно определитБ методБг с дружественнБгми именами, 
лишб осложннгот ситуациго. Думаго, зто излишннн сложностб, к тому же вбгзов 
методов с дружественнБгми именами внгзовет снижение бБгстродеиствин, если толб- 
ко JIT -компилитор не будет способен подставлнтк код в метод с дружественнвгм 
именем. Подстановка кода позволит JIT -компиллтору оптимизироватв весБ код 
путем удаленгш дополнителБного внгзова метода и тем самвгм повбгситб скоростБ 
вБгполненгш. 

ПРИМЕЧАНИЕ 

Примером типа, в котором перегружакггса операторБ! и исполБзуготса дружественнме 

имена методов в соответствии с правилами Microsoft, может служитБ класс System. 

Decimal библиотеки FCL. 


МетодБ! операторов преобразованил 

Времн от времени возникает необходимоств в преобразовании обвекта одного типа 
в oć'bCKT другого типа. Уверен, что вам приходилосв преобразовБгватБ значение Byte 
в Int32. Когда исходнбги и целевои типбг ивлнготси примитивнвгми, компиллтор 
способен без постороннеи помогци генерироватБ код, необходимБги дли преобра- 
зовангш оОЂекта. 

Если ни один из типов не ивлиетсн примитивнБгм, компиллтор генерирует код, 
заставлнгогции CLR вбгполнитб преобразование (приведение типов). В зтом слу- 
чае CLR просто провериет, совпадает ли тип исходного обвекта с целеввгм типом 
(или чвлиетсл производнБгм от целевого). Однако иногда требуетсн преобразоватв 
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обЂект одного типа в совершенно другои тип. Например, класс System .Xml . Linq . 
XElement позволлет преобразоватЂ злемент XML в Boolean, (U)Int32, (U)Int64, 
Single, Double, Decimal, Stning, DateTime, DateTimeOffset, TimeSpan,Guid или 
зквивалент лгобого из зтих типов, допускакиции присваивание null (кроме Stning). 
Также можно представитБ, что в FCL естБ тип даннБ 1 х Rational, в которвш удобно 
преобразовБшатБ о 6 бсктб 1 типа Int32 или Single. Более того, 6 бшо 6 б 1 полезно 
иметБ возможностб вбшолнитб обратное преобразование обвекта Rational в Int32 
или Single. 

Дли вБшолненгш зтих преобразовании в типе Rational должнб 1 определитБСл 
открБ1ТБ1е конструкторБ1, принимагогцие в качестве единственного параметра зкзем- 
плнр преобразуемого типа. Кроме того, нужно определитв открБгтБп! зкземплнрнБпг 
метод ТоХхх, не принимагогции параметров (как популлрнБги метод ToStning). 
КаждБги такои метод преобразует зкземплнр типа, в котором определен зтот метод, 
в зкземплнр типа Ххх. Вот как правилБно определитБ соответствугогцие конструк- 
торвг и методБг длл типа Rational: 

public sealed class Rational { 

// Создает Rational из Int32 
public Rational(Int32 num) { ... } 

// Создает Rational из Single 
public Rational(Single num) { ... } 

// Преобразует Rational в Int32 
public Int32 ToInt32() { ... } 

// Преобразует Rational в Single 
public Single ToSingle() { ... } 

} 

ВБгзБгван зти конструкторвг и мстодбг, разработчик, исполБзун лгобои нзбгк, может 
преобразоватБ обЂект типа Int32 или Single в Rational и обратно. Подобнвге пре- 
образовангш могут 6 бгтб весБма удобнБг, и при проектировании типа стоит подуматв, 
какие конструкторкг и методиг преобразованин имело 6 бг смбгсл вклгочитб в него. 

Ранее мбг обсуждали сиосо 6 бг поддержки перегрузки операторов в разнвгх изБгках. 
Некоторкге (например, С#) нарлду с зтим поддерживагот перегрузку операторов 
преобразованип — методвг, преобразугогцие обиектБг одного типа в о 6 б 6 Ктбг другого 
типа. МетодБг операторов преобразовангш определнготсн при помогци специалБного 
синтаксиса. Спецификацгш CLR требует, что 6 бг перегруженнБге методБг преоб- 
разованин бвгли открБгтвгми и статическими. Кроме того, C# (и многие другие 
избгки) требугот, что 6 бг у метода преобразовангш тип, по краинеи мере, одного из 
параметров или возврагцаемого значенгш совпадал с типом, в котором определен 
операторнБш метод. Причина зтого ограниченгш в том, что оно позволлет ком- 
пилитору C# в разумное времн находитв кандидатурБг операторнБгх методов дли 
привнзки. Следугогции код добавлнет в тип Rational четвгре метода операторов 
прсобразовангш: 
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public sealed class Rational { 

// Создает Rational из Int32 
public Rational(Int32 num) { } 

// Создает Rational из Single 
public Rational(Single num) { ... } 

// Преобразует Rational в Int32 
public Int32 ToInt32() { ... } 

// Преобразует Rational в Single 
public Single ToSingle() { ... } 

// Нелвно создает Rational из Int32 и возврашает полученнми обБект 
public static implicit operator Rational(Int32 num) { 
return new Rational(num); } 

// Нелвно создает Rational из Single и возврацает полученнми обБект 
public static implicit operator Rational(Single num) { 
return new Rational(num); } 

// Авно возвратает обБект типа Int32, полученнми из Rational 
public static explicit operator Int32(Rational r) { 
return r.ToInt32(); } 

// Авно возвратает обБект типа Singlej полученнми из Rational 
public static explicit operator Single(Rational r) { 
return r.ToSingle(); 

} 

} 

При определении методов длн операторов преобразованип следует указатБ, дол- 
жен ли компилптор генерироватБ код длл их ненвного ввиова автоматически или 
лишб при наличии нвного указангш в исходном тексте. Клкзчевое слово implicit 
указвшает компилнтору С#, что наличие в исходном тексте нвного приведенин типов 
не обнзателБно длн генерации кода, вБгзБшагогцего метод оператора преобразованин. 
Клгочевое слово explicit позволлет компилитору ввгзвшатБ метод толбко тогда, 
когда в исходном тексте происходит лвное приведение типов. 

После клгочевого слова implicit или explicit bbi сообгцаете компилнтору, 
что даннБп! метод представлнет собои оператор преобразовангш (клгочевое слово 
operaton). После клгочевого слова operator указвшаетси целевои тип, в которвп! 
преобразуетсл обвект, а в скобках — исходнбш тип обвекта. 

Определив в показанном ранее типе Rational операторБ 1 преобразованин, можно 
написатв (на С#): 

public sealed class Program { 
public static void Main() { 

Rational rl = 5; // Ненвное приведение Int32 к Rational 

Rational r2 = 2.5F; // Неввное приведение Single к Rational 

Int32 х = (Int32) rl; // авное приведение Rational к Int32 

Single s = (Single) r2; // Лвное приведение Rational к Single 

} 
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При исполнении отого кода «за кулисами» происходит следукицее. Компилитор 
C# обнаруживает в исходном тексте операции приведенин (преобразованин типов) 
и при помовди внутренних механизмов генерирует IL -код, которми вмзмвает методм 
операторов преобразовантш, определеннме в типе Rational. Но каковм имена отих 
методов? На отот вопрос можно ответитБ, скомпилировав тип Rational и изучив его 
метаданнме. Оказмваетсн, компилнтор генерирует по одному методу длл каждого 
из определеннмх операторов преобразовангш. Метаданнме четмрех методов опе- 
раторов преобразовашш, определеннмх в типе Rational, вмгллдит примерно так: 

public static Rational op_Implicit(Int32 num) 
public static Rational op_Implicit(Single num) 
public static Int32 op_Explicit(Rational г) 
public static Single op_Explicit(Rational г) 

Как видите, методм, вмполннкнцие преобразование обвектов одного типа в обв- 
ектм другого типа, всегда назмвакзтсл op_Implicit или op_Explicit. ОпределитЂ 
оператор неивного преобразовангш следует, толђко когда точностб или величина 
значенин не териетсл в резулћтате преобразованин, например при преобразовании 
Int32 в Rational. Если же точностб или величина значешш в резулБтате преобра- 
зовангш терлетсн (например, при преобразовании обвекта типа Rational в Int32), 
следует определитБ оператор нвного преобразовании. Если попмтка нвного пре- 
образовангш завершитси неудачеи, следует сообгцитБ об зтом, вмдав в методе ис- 
клкзчение OvenflowException или InvalidOperationException. 


ПРИМЕЧАНИЕ 

Два метода с именем op_Explicit приниманзт одинаковв 1 и параметр — обвект типа 
Rational. Но зти методв! возвраидакзт значении разннх типов: Int32 и Single соот- 
ветственно. Зто пример napu методов, отличаккцихсч лишвтипом возвраидаемого 
значенич. CLR в полном обЂеме подцерживает возможностђ определенич несколвких 
методов, отличакзидихсн толђко типами возвраидаемв 1 х значении. Однако зта воз- 
можностђ исполЂзуетсч лииљ оченЂ немногими чзв 1 ками. Как вм, верочтно, знаете, 
С++, С#, Visual Basic и Java не позволчкдтопределчтЂ методЕЈ, различакзидиесч толвко 
типом возвраидаемого значенич. Лишђ несколЂко чзнков (например, IL) позволчкгг 
разработчику чвно внбиратЂ, какои метод вЂ13ватЂ. Конечно, IL -программистам не 
следует исполвзоватЂ зту возможностђ, так как определеннЂ 1 е таким образом методи 
будут недоступнЂ! длч вЂ130ва из программ, написаннмх на других чзЂ1ках програм- 
мированич. И хотч C# не предоставлчет зту возможностђ программисту, внутренние 
механизмЂ! компилчтора все равно исполЂзукзт ее, если в типе определенв! методв! 
операторов преобразованич. 


Компилнтор C# полностБго поддерживает операторБг преобразовашш. Обнару- 
жив код, в котором вместо ожидаемого типа исполвзуетсц обБект совсем другого 
типа, компилптор шцет метод оператора ненвного преобразовангш, способнвш вбг- 
полнитб нужное преобразование, и генерирует код, вБгзБшагогции зтот метод. Если 
подходагции метод оператора ненвного преобразовангш обнаруживаетсн, компилнтор 
вставлнет в резулвтиругогции IL -код вбгзов зтого метода. I laii/ui в исходном тексте 


234 Глава 8. Методм 


нвное приведение типов, компилнтор ивдет метод оператора нвного или непвного 
преобразованил. Если он сугцествует, компиллтор генерирует вмзмваклции его код. 
Если компилитор не может наити подходнгции метод оператора преобразованин, он 
вмдает ошибку, и код не компилируетсн. 

ПРИМЕЧАНИЕ 

C# генерирует код Bbi30Ba операторов нелвного преобразованил в случае, когда 
исполвзуетсл ви 1 ражение приведенил типов. Однако операторм нелвного преоб- 
разованил никогда не Bbi3biBaiOTCH, если исполвзуетсл оператор as или is. 


Чтобм по-настонгцему разобратБСн в методах перегруженнћгх операторов и опе- 
раторов преобразовангш, н настоителБно рекомендуго исполБЗОватБ тип System. 
Decimal как образец. В типе Decimal определено несколБКО конструкторов, по- 
зволигогцих преобразовБшатБ в Decimal обЂектћг различнБгх типов. Он также под- 
держивает несколБКО методов ТоХхх дли преобразовангш обЂектов типа Decimal 
в обЂектм других типов. Е1аконец, в зтом типе определен рид методов операторов 
преобразовангш и перегруженнмх операторов. 


Методн расширенил 

Механизм методов расширенгш лучше всего рассматриватЂ на конкретном примере. 
В главе 14 н упоминаго о том, что дли управленгш строками класс StningBuilder 
предлагает менвше методов, чем класс Stning, и зто доволђно странно, потому 
что класс StringBuilder нвлнетсн предпочтителвнее дли управленгш строками, 
так как он изменнем. Допустим, вм хотите определитЂ некоторме отсутствугогцие 
в классе StringBuilder методм самостонтелвно. Возможно, вм решите определитв 
собственнми метод IndexOf : 

public static class StringBuilderExtensions { 

public static Int32 IndexOf(StringBuilder sb^ Char value) { 
for (Int32 index = 0; index < sb.Length; index++) 
if (sb[index] == value) return index; 
return -1; 

} 

} 

После того как метод будет определен, его можно исполвзоватЂ в программах: 
// Инициализирукхцаз строка 

StringBuilder sb = new StringBuilder("Hello. Му name is 3eff."); 

// Замена точки восклицателцнмм знаком 

// и получение номера символа в первом предложении (5) 

Int32 index = StringBuilderExtensions . IndexOf(sb . Replace( ’.' л '!'), '!'); 
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Зтот программнми код работает, но в перспективе он не идеален. Во-первмх, про- 
граммист, желакнции получитБ индекс символа при помогци класса StringBuilden, 
должен знатБ о сугцествовании класса StningBuilderExtensions. Во-вторБгх, 
программнБпг код не отражает последователБностБ операторов, представленнвгх 
в обвекте StningBuilden, что усложннет понимание, чтение и сопровождение кода. 
Программистам удобнее бвшо 6bi вБгзвшатБ сначала метод Replace, а затем метод 
IndexOf , но когда вбг прочитаете последнгого строчку кода слева направо, перввгм 
в строке окажетсл IndexOf, а затем — Replace. Вбг можете исправитБ ситуациго 
и сделатБ поведение программного кода более поннтнбш, написав следугогции код: 

// Замена точки восклицателинмм знаком 
sb.Replace( '.', '!’); 

// Получение номера символа в первом предложении (5) 

Int32 index = StningBuilderExtensions . IndexOf(sb, '!')г 

Однако здесв возникает третвл проблема, затруднигогцаи понимание логггки 
кода. ИсполБЗОвание класса StningBuildenExtensions отвлекает программиста 
от вБгполнпемои операцгш: IndexOf. Если 6бг класс StningBuilden определлл 
собственнБш метод IndexOf, то представленнБги код можно 6бгло 6бг переписатБ 
следугогцим образом: 

// Замена точки восклицателцнмм знаком 

// и получение номера символа в первом предложении (5) 

Int32 index = sb.Replace( '.', ’!'). IndexOf ('!’); 

B контексте сопровожденгш программного кода зто вбгглидит великолепно! 
В оођсктс StningBuilden мбг заменнем точку восклицателБНБгм знаком, а затем 
находим индекс зтого знака. 

А сеичас л попробуго о6ђнснитб, что именно делагот методпг расширенин. Онгг 
позволпгот вам определитв статическии метод, которБги вБгзБгваетсл посредством 
синтаксиса зкземплирного метода. Иначе говори, мбг можем определитБ собствен- 
нбги метод IndexOf — и тргг проблемБг, упомннутБге вБгше, исчезнут. Длн того что6бг 
превратитБ метод IndexOf в метод расширенин, мбг просто добавим клгочевое слово 
this перед перввгм аргументом: 

public static class StningBuildenExtensions { 

public static Int32 IndexOf(this StningBuilden sb, Chan value) { 
fon (Int32 index = 0; index < sb.Length; index++) 
if (sb[index] == value) netunn index; 
netunn -1; 

} 

} 

Компшштор увидит следугогции код: 

Int32 index = sb.IndexOf( 'X' ); 

Сначала он проверит класс StningBuilden или все его базоввге классБг, предо- 
ставлнгогцие зкземплирнвге методБг с именем IndexOf и единственнБгм параметром 
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Chan. Если они не сушествугот, тогда компилитор будет искатБ лгобои статическии 
класс с определеннБш методом IndexOf, у которого nepBbiii параметр соответствует 
типу вБфаженин, исполБзуемого при вБ130ве метода. Зтот тип должен 6bitb отмечен 
при помогци клгочевого слова this. В данном примере ввфажением нвллетсл sb 
типа StningBuilden. В зтом случае компилнтор игцет метод IndexOf с двумл па- 
раметрами: StningBuilden (отмеченное словом this) и Chan. Компилнтор наидет 
наш метод IndexOf и сгенерирует IL -код длл ввгоова нашего статического метода. 

Теперв поннтно, как компиллтор решает две последние упоминутвге мнои про- 
блемБ 1 , относигциесл к читабелБности кода. Однако до сих пор непонлтно, как 
решаетсл первал проблема, то еств как программистБг узнагот о том, что метод 
IndexOf сугцествует и может исполвзоватБСн в обвекте StningBuilden? Ответ на 
зтот вопрос в Microsoft Visual Studio дает механизм IntelliSense. В редакторе, когда 
вб 1 напечатаете точку, полвитсл IntelliSense -окно со списком доступнмх методов. 
Кроме того, в IntelliSense -окне будут представленм все методвг расширенгш, су- 
гцествугогцие длн типа ввграженгш, написанного слева от точки. IntelliSense -окно 
показано на рис. 8.1. Как видите, рндом с методами расширенгш имеетсл стрелочка, 
а контекстнал подсказка показвгвает, что метод деиствителБно нвллетсл методом 
расширенгш. Зто оченв удобно, потому что теперн при помогци зтого инструмента 
вб1 можете легко определлтБ собственнБге методБг длл управленгш различнБши 
типами обвектов, а другие программиствг естественнБгм образом узнагот о них при 
исполБЗОвангш обвектов зтих типов. 
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Рис. 8.1. Метод расширениа в окне IntelliSense в Visual Studio 
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Правила и рекомендации 

Приведу несколБКО правил и фактов, которме необходимо знатБ о методах рас- 

ширенин. 

□ Нзб1К C# поддерживает толбко мстодб1 расширенип, он не поддерживает своиств 
расширенин, со6б1тии расширенин, операторов расширенин и т. д. 

□ МетодБ1 расширенин (методБ1 со словом this перед перввш аргументом) должнб1 
6б1тб обБнвленБ1 в статическом необобнденном классе. Однако нет ограниченин 
на ими зтого класса, bbi можете назватв его как вам угодно. Конечно, метод 
расширешш должен иметв, по краинеи мере, один параметр, и толбко первкш 
параметр может 6 б1тб отмечен клкзчевБш словом this. 

□ Компилитор C# шцет методБ1 расширенин, заданнБ1е толбко в статических 
классах, определеннБ1х в области видимости фаила. Другими словами, если bbi 
определили статическии класс, унаследованнБП! от другого класса, компшштор 
C# вБвдаст следуклцее сообндение (ошибка CSl 109: метод расширешш должен 
6 б1тб определен в статическом классе первого уровнн, StningBuilderExtensions 
ивллетси вложеннБш классом): 

еггог CS1109: Extension method must be defined in a top-level static 
class; StringBuilderExtensions is a nested class 

□ Так как статическим классам можно даватк .noobie имена по вашему желаншо, 
компилнтору C# необходимо какое-то времн длн того, что6б 1 наити методБ1 рас- 
ширешш; он просматривает все статические классвц определеннБ1е в области 
фаила, и сканирует их статические методБк Длл повБшенин производителБности 
и длл того, что6б 1 не рассматриватн лишние в даннБ1х обстоителБСтвах методБ1 
расширешш, компилитор C# требует <<импортирован1ш» методов расширешш. 
Например, пуств кто-нибудБ определил класс StringBuilderExtensions в про- 
странстве имен Wintellect, тогда другои программист, которому нужно иметв 
доступ к методу расширешш данного класса, в начале фаила программного кода 
должен указатв команду using Wintellect. 

□ Сушествует возможностб определенил в несколвких статических классах 
одинаковБ 1 х методов расширешш. Если компилнтор вбшснит, что сушествугот 
два и более методов расширешш, то тогда он вввдает следукнцее сообниепие 
(ошибка CS0121: неоднозначнБ 1 и вбгоов следукицих методов или своиств 

'StringBuilderExtensions . IndexOf(stringj char) ' и 'AnotherStringBuild 
erExtensions.IndexOf(string^ char)): 

еггог CS0121: The call is ambiguous between the following methods 
ог properties: ’StringBuilderExtensions.IndexOf(string, char)' 
and 'AnotherStringBuilderExtensions.IndexOf(string, char)'. 

Длл того что6б 1 исправитБ зту ошибку, вб1 должнб 1 модифицироватБ про- 
граммнБШ код. НелБЗн исполбзовдтб синтаксис зкземшшрного метода длл вкгоова 
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статического метода, вместо зтого должен применнтБСн синтаксис статического 
метода с указанием имени статического класса, чтобм точно сообгцитБ компи- 
литору, какои именно метод нужно вмзватБ. 

□ ПрибегатБ к зтому механизму следует не слишком часто, так как он известен не 
всем разработчикам. Например, когда bbi расширнете тип с методом расширенин, 
вб 1 деиствителБно расширлете унаследованнБге i ihii.i с зтим методом. Следова- 
телБно, вб1 не долж 11i.i определнтБ метод вБграженгга, чеи первБги параметр — 
Sy stem . Ob ј ect, так как зтот метод будет вБгзБшатБСн длн всех типов вБфажении, 
и соответствугогцие ссбшки толбко будут загромождатк окно IntelliSense. 

□ Сугцествует потенциалБнан проблема с версггами. Если в будугцем разработчики 
Microsoft добавит зкземплнрнми метод IndexOf к классу StningBuilder с тем 
же прототипом, что и в моем примере, то когда л перекомпилируго свои про- 
граммнвш код, компилитор свнжет с программои зкземплнрнБпг метод IndexOf 
компании Microsoft вместо моего статического метода IndexOf . Из-зазтого мом 
программа начнет себн по-другому. Зта проблема версии — егце одна причина, 
по которои зтот механизм следует исполвзоватв осмотрителБно. 


Расширение разнмх типов методами расширенин 

В зтои главе и продемонстрировал, как определнтв методБг расширенгга длн класса 
StringBuilder. Л хотел 6 бг отметитБ, что так как метод расширенгга на самом деле 
нвлнетсл вБгзовом статического метода, то среда CLR не генерирует код длл проверки 
значенгга ввфаженгга, исполБзуемого дли вБгзова метода (равно ли оно null). 

// sb равно null 
StringBuilder sb = null; 

// BbBOB метода вмраженин: искличение NullReferenceException HE БУДЕТ 
// видано при визове IndexOf 

// Исклн 5 чение NullReferenceException будет вброшено внутри цикла IndexOf 
sb.IndexOf ('X'); 

// Вшзов зкземпллрного метода: исклшчение NullReferenceException БУДЕТ 
// вброшено при вшзове Replace 
sb.Replace( '.', ' !’); 

И также хотел 6бг отметитБ, что вбг можете определлтБ методБг расширенгга длн 
интерфеиснБгх типов, как в следугогцем программном коде: 

public static void ShowItems<T>(this IEnumerable<T> collection) { 
foreach (var item in collection) 

Console.WriteLine(item); 

} 

ПредставленнБш здесБ метод расширенгга может 6 бгтб вБгзван с исполБЗОванием 
лгобого вБграженгга, резулБтат вБшолненгга которого относитсл к типу, реализуго- 
гцему интерфеис IEnumerable<T>: 
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public static void Main() { 

// Показивает каждми символ в каждои строке консоли 
"Grant".ShowItems( ); 

// Показнвает каждук) строку в каждои строке консоли 
new[] { "Deff'j "Kristin" }.ShowItems(); 

// Показивает каждми Int32 в каждои строчке консоли. 
new List<Int32>() { 1, 2, 3 }.ShowItems(); 

} 

ВНИМАНИЕ 

Методн расширенип пвлпк)тсп KpaeyroabHbiM камнем предлагаемои MicrosoftTexHO- 
логии Language Integrated Query (LINQ). B качествехорошего примера класса с боли- 
шим количеством методов расширенил обратите внимание на статическии класс 
System.Linq.Enumerable и все его статические методм расширенил в документации 
Microsoft .NET FrameworkSDK. Каждми метод расширенил в зтом классе расширлет 
либо интерфеис lEnumerable, либо интерфеис IEnumerable<T>. 


Методм расширепии также можно определнтБ и длл типов-делегатов, напри- 
мер: 

public static void InvokeAndCatch<TException>(this Action<Object> d., Object o) 
where TException : Exception { 
try { d(o); } 
catch (TException) { } 

} 


Пример вБгзова: 

Action<Object> action = o => Console.WriteLine(o.GetType()); 

// Вндает NullReferenceException 
action.InvokeAndCatch<NullReferenceException>(null); 

// Поглоцает NullReferenceException 

Кроме того, можно добавлнтБ методБ 1 расширенил к перечислимБш типам (при- 
мерБ 1 см. в главе 15). 

Наконец, компилнтор C# позволиет создаватв делегатов, ссБшагогцихсн на метод 
расширенин через обвект (см. главу 17): 
public static void Main () { 

// Создание делегата Action, ссмлакицегосл на статическии метод расширенил 
// ShowItems; первми аргумент инициализируетсл ссшлкои на строку "Deff" 

Action а = "Deff".ShowItems; 


// Вшзов делегатаЈ визмваккцего ShowItems и передаклцего 
// ссшлку на строку "Deff" 

а«; 

} 
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В представленном программном коде компшштор C# генерирует IL -код длл того, 
чтобм создатБ делегата Action. После созданин делегата конструктор передаетси 
в ББ13Б1ваемБш метод, также передаетсл ссвшка на обвект, которБпт должен 6 бтгб 
передан в зтот метод в качестве скрвгтого параметра. Обвшно, когда bbi создаете 
делегата, ссвшакнцегосн на статическии метод, обвектнаи ссвшка равна null, по- 
тому что статическии метод не имеет зтого параметра. Однако в данном примере 
компилнтор C# сгенерирует специалвнБп! код, создаклции делегата, ссБшакнцегосн 
на статическии метод ShowItems, а целевБш обвектом статического метода будет 
ссБшка на строку "Deff ". Позднее, при вБ130ве делегата, CLR вввовет статическии 
метод и передаст ему ссвшку на строку "Deff ", Все зто напоминает какие-то фо- 
кусв 1 , но хорошо работает и вбшллдит естественно, если не думатв, что при зтом 
происходит внутри. 


Атрибут расширенил 

Конечно, 6 бшо 6 б 1 лучше, что 6 б 1 концепцгш методов расширенгш относиласв 6 бг 
не толбко к С#. ХотелосБ 6 бе, что6бг программистБг определнли набор методов 
расширенин на разнвгх нзБгках программировании и, таким образом, способство- 
вали развитиго других нзбгков программированин. Длл того чтобвг зтот механизм 
работал, компшштор должен поддерживатв поиск статичнкгх типов и методов длл 
сопоставленгш с методами расширенин. И компилиторБг должнбг зто проделБгватБ 
бБгстро, что6бг времн компилиции оставалосБ минималБНБгм. 

В изБгке С#, когда вбг помечаете первБги параметр статичного метода клгочевБгм 
словом this, компилитор применнет соответствугогции атрибут к методу, и даннвги 
атрибут сохраннетсн в метаданнвгх резулБтггругогцего фаила. Зтот атрггбут определен 
в сборке System.Core.dll и вбггллдит следугогцим образом: 

// Определен в пространстве имен System.Runtime.CompilerServices 
[Attributellsage(AttributeTargets .Method | AttributeTargets .Class 

| AttributeTargets. 

Assembly)] 

public sealed class ExtensionAttribute : Attribute { 

} 

K тому же зтот атрибут применнетсн к метаданнкгм лгобого статического класса, 
содержагцего, по краинеи мере, один метод расширенгш. Итак, когда скомпилиро- 
ваннБги код вБгзБгвает несугцествугогции зкземплнрнвги метод, компилитор может 
бкгстро просканироватБ все ссвглагогциеси сборки, чтобкг определитБ, какан из них 
содержит методБг расширенгш. В далБнеишем он может сканироватБ толбко те 
сборки статических классов, которвге содержат методвг расширенин, вбгполннн 
поиск потенциалБНБгх соответствии компилируемому коду настолвко бкгстро, на- 
СКОЛБКО зто возможно. 
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ПРИМЕЧАНИЕ 

Класс ExtensionAttribute определен в сборке System.Core.dll. Зто означает, что резулБ- 
тирукзш,ап сборка, сгенерированнач компилчтором, будет иметв ссмлку на встроен- 
нуко в нее библиотеку System.Core.dll, даже если не исполвзоватв какои-либо тип из 
System.Core.dll и даже если не ccbmaTbcn на него во времл компиллции программного 
кода. Однако зто не такал уже болишал проблема, потому что ExtensionAttribute ис- 
полизуетсл толико один раз во времл компиллции, и во времл внполненил System. 
Core.dll не загрузитсл, пока приложение занлто чем-либо другим в зтои сборке. 


Частичнне методБ! 

Представете, что вм испо./њзусте служебпук) программу, которап генерирует ис- 
ходнми код на C# с определением типа. Зтои программе известно, что внутри 
программного кода естБ места, в которБ 1 х Bbi хотели 6bi настроитБ поведение типа. 
06 б 1 чно такан настроика производитси при помогци виртуалБнмх методов, вмзм- 
ваеммх сгенерированнмм кодом. Сгенерированнми код также должен содержатБ 
определенгш зтих виртуалБнмх методов, где их реализации ничего не делает, а про- 
сто возврагцает управление. Чтобм настроитБ поведение класса, нужно определитБ 
собственнми класс, унаследованнми от базового, и затем переопределитБ все его 
виртуалБнме методм, реализугогцие желаемое поведение. Вот пример: 

// Сгенерированнни код в некотором фаиле с исходннм кодом: 
internal class Base { 
private String m_name; 

// Внвмваетсл перед изменением полл m_name 
protected virtual void OnNameChanging(String value) { 

} 

public String Name { 
get { return m_name; } 
set { 

// Информирует класс o возможнмх измененилх 
OnNameChanging(value.ToUpper()); 
m_name = value; // Изменение полл 

} 

} 

} 

// Написаннни программистом код из другого фаила 
internal class Derived : Base { 

protected override void OnNameChanging(string value) { 
if (String.IsNullOrEmpty(value)) 

throw new ArgumentNullException("value"); 

} 

} 
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К сожаленшо, у представленного кода имеготси два недостатка. 

□ Тип не должен 6мтб запечатаннмм (sealed) классом. НелБЗи исполћзоватБ зтот 
подход длл запечатаннБ1х классов или длл значимБ1х типов (потому что значи- 
мбш типб1 неивно запечатанБ1). К тому же нелБЗи исполБЗОватБ зтот подход длн 
статических методов, потому что они не могут переопределлтБСи. 

□ Сугцествует проблема зффективности. Тип, определнемБпт толбко длн переопре- 
деленгш метода, понапрасну расходует некоторое количество системнвш ресур- 
сов. И даже если iii>i не хотите переопределнтБ поведение типа OnNameChanging, 
код базового класса по-прежнему ввгоовет виртуалвнБш метод, которБпг помимо 
возврата управленин ничего болвше не делает. Метод ToUppen вБИБшаетсл и тог- 
да, когда OnNameChanging получает доступ к переданнБш аргументам, и тогда, 
когда не получает. 

Длн решенгш проблемБ1 переопределенгш поведенгш можно задеиствоватв ча- 
CTii'iiibie методБг чзБ1ка С#. В следугогцем коде длл достиженгш тои же семантики, 
что и в предБгдугцем коде, исполБзуготсл частичнБШ методБг: 

// Сгенерированнми при помоци инструмента программнми код 
internal sealed partial class Base { 
private String m_nartie; 

// Зто обкпвление c определением частичного метода вмзмваетсл 

// перед изменением полп m_name 

partial void OnNameChanging(String value); 

public String Name { 
get { return m_name; } 
set { 

// Информирование класса o потенциалБном изменении 
OnNameChanging(value.ToUpper()); 
m_name = value; // Изменение полп 

} 

} 


// Написаннми программистом код, содержашиисв в другом фаиле 
internal sealed partial class Base { 

// Зто обкввление c реализациеи частичного метода BbBbiBaeTCB перед тем, 

// как будет изменено поле m_name 
partial void OnNameChanging(String value) { 
if (String.IsNullOrEmpty(value)) 
throw new ArgumentNullException("value"); 

} 

} 

B зтом коде естБ несколБКО мест, на которте необходимо обратитн внимание. 

□ Теперв класс запечатан (хотн зто и не обчзателБно). В деиствителБности, класс 
мог 6 ki 6б1тб статическим классом или даже значимкш типом. 
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□ Код, сгенерированнми программои, и код, написаннБ 1 и программистом, на самом 
деле ивлнготси двумн частичнБши определенинми, которБге в конце концов об- 
разугот одно определение типа (подробности см. в главе 6). 

□ Код, сгенерированнБш программои, представлнет собои обЂивление частичного 
метода. Зтот метод помечен клгочевмм словом pantial и не имеет тела. 

□ Код, написаннми программистом, реализует обвнвление частичного метода. Зтот 
метод также помечен клгочевмм словом pantial и тоже не имеет тела. 

Когда вм скомпилируете зтот код, вм увидите то же самое, что и в представлен- 
ном ранее коде. БолЂшое преимугцество такого решешш заклгочаетсл в том, что 
вм можете перезапуститБ программу и сгенерироватБ новми код в новом фаиле, 
а ваш программнми код по-прежнему останетсн нетронутмм в отделћном фаиле. 
Кроме того, зтот подход работает дли изолированнмх классов, статических классов 
и значиммх типов. 

ПРИМЕЧАНИЕ 

В редакторе Visual Studio, если ввести partial и нажатБ пробел, в окне IntelliSense 
полвлтсл обЂлвленип всех частичнмх методов вложенного типа, KOTopbie пока не 
имекзт соответствил обЂлвленилм внполнлемого частичного метода. Bbi легко можете 
внбрате частичнни метод в lntelliSense -окне, и Visual Studio сгенерирует прототип 
метода автоматически. Зто оченв удобнал функцил, noebiujaiouj,an производители- 
HOCTb программированил. 


У частичнмх методов имеетсл егце одно серћезное преимугцество. Скажем, у вас 
теперБ нет нужнм модифицироватћ поведение типа, сгенерированного инструмен- 
том, и меннтБ фаил исходного кода. Если просто скомпилироватБ такои код, ком- 
пилитор создаст IL -код и метаданнБге, как если 6бг сгенерированнБпг программои 
код вБгглидел следугогцим образом: 

// Логическии зквивалент сгенерированного инструментом кода в случае, 

// когда нет обБнвленил виполнлемого частичного метода 
internal sealed class Base { 
private String m_name; 

public String Name { 
get { return m_name; } 
set { 

m_name = value; // Измените поле 

} 

} 

} 

При отсутствии обЂивленгш вБшолннемого частичного метода компиллтор не 
будет генерироватБ метаданнБге, представлнгогцие частичнвпг метод. К тому же ком- 
пилитор не сгенерирует IL -командБг вБгзова частичного метода, он не сгенерирует 
код, вБгчислнгогции аргументБг, которБге необходимо передатБ частичному методу. 
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В приведенном примере компилнтор не сгенерирует код длн вмзова метода ToUpper. 
В резулетате будет меш>шс метаданнмх и IL -кода и производителБностћ во времи 
вмполненин повмситси! 

ПРИМЕНАНИЕ 

IIOAOČHbiM образом частичнме методв! работакзт с атрибутом System.Diagnostics. 
ConditionalAttribute. Однако они работакзт тснљко с одним типом, тогда как атрибут 
ConditionalAttribute может 6biTb исполвзован длл необлзателиного вмзова методов, 
определеннмх в другом типе. 


Правила и рекомендации 

Несколвко дополнителћнмх правил и рекомендации, касагогцихси частичнмх ме- 

тодов. 

□ Частичнме методм могут о6ђнвлнтбси толбко внутри частичного класса или 
структурм. 

□ Частичнме методм должнм всегда иметћ возврагцаемми тип void и не могут 
иметћ параметров, помеченнмх клгочевмм словом out. Зти ограниченгш свнзанм 
с тем, что во времн вмполненин программм метода не сугцествует, и вм не можете 
инициализироватБ переменнуго, возврагцаемуго методом, потому что зтого метода 
не сугцествует. По тои же причине нелБЗи исполБЗОватБ параметр, помеченнБги 
словом out, потому что иначе метод должен будет инициализироватБ зтот пара- 
метр, но зтого метода не сугцествует. Частичнвги метод может иметБ параметрБг, 
помеченнБге клгочевБгм словом nef , а также универсалвнБге параметрБг, зкзем- 
плирнБге или статические, или даже параметркг, помеченнБге как unsafe. 

□ Естественно, определнгогцее обБнвление частичного метода и его реализугогцее 
обвнвление должнбг иметБ идентичнБге сигнатурБг. И оба должнбг иметБ на- 
страивагогцггесн атрибутвг, прггменнгогцггесн к нггм, когда компгглнтор обБедггнлет 
атрибутБг обоггх методов вместе. Все атрибутвг, прггменнемБге к параметрам, 
тоже о6бсди1ш iotc и. 

□ Если не сугцествует реалггзугогцего обБнвленгш частичного метода, в вашем коде 
не может 6бгтб попбгток создангш делегата, ссБглагогцегоси на частичнБги метод. 
Зто причггна, по которогг метод не сугцествует во времн вБгполнешш программнг. 
Компгглнтор вБгдаст следугогцее сообгценгге (ошибка CS0762: не могу создатБ 
делегатаиз метода ' Base .OnNameChanging(string) ', потому что зто частичнБш 
метод без реализугогцего обБнвленгш): 

"error CS0762: Cannot create delegate from method 

'Base.OnNameChanging(string)' because it is a partial method 
without an implementing declaration 

□ Хотн частичнБге методБг всегда считаготсн закрвгтБгми, компилнтор C# запрегцает 
писатБ клгочевое слово private перед обБнвленггем частичного метода. 
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В зтои главе рассмотренм различнме способм передачи параметров в метод. В числе 
прочего вм узнаете, как определитБ необизателБНБш параметр, задатп параметр по 
имени и передатБ его по сспшке. Также рассмотрена процедура определенип методов, 
принимаклцих различное количество аргументов. 


НеоблзателБнне и именованнне параметрм 1 

При BBi6ope параметров метода некоторвш из них (и даже всем) можно присваиватв 
значенин по умолчаниго. В резулнтате в вввБшаклцем такои метод коде можно не 
указБшатБ зти аргументБц а приниматБ уже имеклциесл значенил. Кроме того, при 
вБ130ве метода сугцествует возможностб указатБ аргументБ1, восполБЗОвавшисБ 
именами их параметров. Следуклции код демонстрирует применение как необл- 
зателвнБ1Х, так и именованнБ1х параметров: 

public static class Pnogram { 
private static Int32 s_n = 0; 

private static void M(Int32 х = 9, String s = "A", 

DateTime dt = default(DateTime), Guidguid = new Guid()) { 
Console.WriteLine("x={0}, s={l}j dt={2}, guid={3}", х, s, dt, guid); 

} 

public static void Main() { 

// 1. Аналогично: M(9, "A", default(DateTime), new Guid()); 

M(); 

// 2. Аналогично: M(8, "X", default(DateTime), new Guid()); 

M(8, "X"); 

// 3. Аналогично: M(5, "A", DateTime.Now, Guid.NewGuid()); 

M(5, guid: Guid.NewGuid(), dt: DateTime.Now); 

// 4. Аналогично: M(0, "1", default(DateTime), new Guid()); 

M(s_n++, s_n++.ToString()); 

// 5. Аналогично: String tl = "2"; Int32 t2 = 3; 

// M(t2, tl, default(DateTime), new Guid()); 

M(s: (s_n++) .ToStringO, х: s_n++); 

} 

} 


При вБшолнении зтого кода вбшодитсл следуклции резуллтат: 

x=9j s=Aj dt=l/l/0001 12:00:00 AMj guid=00000000-0000-0000-0000-000000000000 
x=8j s=Xj dt=l/l/0001 12:00:00 AMj guid=00000000-0000-0000-0000-000000000000 

продолжение & 

1 B настолшии момент в msdn.microsoft.com исполБзуетсл термин «необлзателБнме и име- 
нованнне аргументБ 1 », но автор в даннои книге назвшает их «параметрами». Mhi решили 
сохранитБ авторскуго терминологшо. — Примеч. ред. 
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х=5 j s=A, dt=8/16/2012 10:14:25 PMj guid=d24a59da-6009-4aae-9295-839155811309 
x=0j s=lj dt=l/l/0001 12:00:00 AMj guid=00000000-0000-0000-0000-000000000000 
x=3, s=2, dt=l/l/0001 12:00:00 AM, guid=00000000-0000-0000-0000-000000000000 

Как видите, в случае если при вмзове метода аргументм отсутствукзт, компилнтор 
берет их значенин, предлагаемме по умолчаншо. В третБем и пнтом вБ130вах метода 
М заданБ 1 именованние параметри (named parameter). Л в ивном виде передал зна- 
чение переменнои х и указал, что хочу передатв аргумент длн параметров guid и dt. 

Передаваемвге в метод аргументБ 1 компиллтор рассматривает слева направо. 
В четвертом ввшове метода Мзначение аргумента s_n (0) передаетсл в переменнук) х, 
затем s_n увеличиваетсл на единицу и аргумент s_n (1) передаетсл как строка 
в параметр s. После чего s_n увеличиваетсл до 2. Передача аргументов с помогцбкз 
именованнБгх параметров опнтб же осугцествлиетсл компилнтором слева направо. 
В пнтом ввгзове метода М значение параметра s_n (2) преобразуетсн в строку и со- 
храннетсн в созданнои компилитором временнои переменнои (tl). Затем s_n уве- 
личиваетси до 3, и зто значение сохраннетси в егце однои созданнои компилнтором 
временнои переменнои (t2). После зтого s_n увеличиваетсл до 4. В конце концов, 
ББ13Б1ваетсн метод М, в которвш передаготсн переменнвге t2, tl, переменнан DateTime 
со значением по умолчаншо и новое значение Guid. 

Правила исполвзованил параметров 

Определин метод, задагогции длн части своих параметров значенгш по умолчаниго, 
следует руководствоватвсн следугогцими правилами: 

□ Значенгш по умолчаниго указвгваготсл длн параметров методов, конструкторов 
методов и параметрических своиств (индексаторов С#). Также их можно ука- 
звгватБ длл параметров, нвлнгогцихсл частвго определенин делегатов. В резулв- 
тате пргг вБгзове зтого типа делегата аргументвг можно опускатБ, исполБзун их 
значенин по умолчаниго. 

□ ПараметрБг со значенинми по умолчаниго должнбг следоватБ за всемгг осталБНБгми 
параметрами. Другими словами, еслгг указан параметр со значением по умолчаниго, 
значенгш по умолчаниго должнбг ггметБ и все параметрвг, расположеннвге справа от 
него. Например, если пргг определении метода М удалитв значение по умолчаниго 
("А") длл параметра s, компилнтор внгдаст сообгцение об ошибке. Сугцествует 
толбко одно ггсклгочение из правил — параметр массива, помеченнБш клгочевБгм 
словом panams (о котором мбг подробно поговорим чутв позже). Он должен рас- 
полагатБСн после всех прочих параметров, в том числе имегогцих значение по 
умолчаниго. Пргг зтом сам массггв значенгш по умолчаниго ггметв не может. 

□ Во времл компгглнцгги значенин по умолчаниго должнбг оставатБСн неизменнБгми. 
То естБ задаватБ значенгш по умолчаниго можно длл параметров примитивнвгх 
типов, перечисленнБгх в табл. 5.1 главвг 5. Сгода относлтсл также перечисли- 
мБге типбг и ссБглочнБге типбг, допускагогцие присвоение значенгш null. Длл 
параметров произволвного значимого типа значение по умолчаниго задаетсл 
как зкземплнр зтого типа с полнми, содержагцими нули. Можно исполБЗОватБ 
как клгочевое слово def ault, так и клгочевое слово new, в обоих случанх генери- 
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рустси одинаковми IL -код. С примерами обоих вариантов синтаксиса мм уже 
встречалисв в методе М при задании значении по умолчаниго длн параметров dt 
и guid соответственно. 

□ Запретцаетсн переименовмватБ параметрические переменнме, так как зто влечет 
за собои необходимостБ редактированин вмзмвагошего кода, которми передает 
аргументн по имени параметра. Скажем, если в обЂнвлении метода М переиме- 
новатБ переменнуго dt в dateTime, то третии вмзов метода станет причинои по- 
нвленгш следугогцего сообгценгш компиллтора (ошибка CS1739: в подходлгцеи 
перегруженноиверсии 'М' отсутствуетпараметрсименем 'dt'): 

"erron CS1739: The best overload for 'M' does not have a parameter 
named 'dt' 

□ Пргг вмзове метода извне модулн изменение значенгш параметров по умолчаниго 
нвлиетсл потенциалБно опаснмм. Вмзмвагогцал сторона исполБзует значение 
по умолчаниго в процессе работм. Если изменитБ его и не перекомпилироватБ 
код, содержагции вбгзов, в вБгзвгваемБги метод будет передано прежнее значение. 
В качестве индикатора поведенгш можно исполвзоватБ значение по умолчаниго 
0 или null. В резулБтате исчезает необходимостБ повторнои компилнции кода 
ББгзБгвагогцеи сторонвг. Вот пример: 

// Не делаите так: 

private static String MakePath(String filename = "Untitled") { 
return String.Format(@"C:\{0}.txt", filename); 

} 

// Исполвзуите следуккцее решение: 

private static String MakePath(String filename = null) { 

// Здеси применлетсл оператор, поддерживакиции 
// значение null (??); см. главу 19 

return String.Format (@"С:\{0} .txt" , filename ?? "Untitled"); 

} 

□ Длн параметров, помеченнвгх клгочевБгми словами ref или out, значенгш по 
умолчаниго не задаготсл. 

Сугцествугот также дополнителвнБге правила ввгзова методов с исполБЗОванием 

необизателвнБгх или именованнБгх параметров: 

□ Аргументвг можно передаватБ в произволвном порндке; но именованнБге аргу- 
ментБг должнбг находитБСл в конце списка. 

□ Передача аргумента по именгг возможна длн параметров, не имегогцих значенгш 
по умолчаниго, но при зтом компилнтору должнбг 6бгтб переданБг все аргументвг, 
необходимБге дли компилнции (с указанием их позиции или имени). 

□ В C# между запнтБгми не могут отсутствоватБ аргументБГ. Иначе говорн, записБ 
М( 1 j j DateTime. Now) недопустима, так как ведет к нечитабелвному коду. Что- 
6бг опуститБ аргумент длл параметра со значением по умолчаниго, передаваите 
аргументвг по именам параметров. 

□ Вот как передатв аргумент по имени параметра, требугогцего клгочевого слова 

ref/out: 
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// Обћавление метода: 

private static void M(ref Int32 х) { ... } 
// Bbi30B метода: 

Int32 a = 5; 

M(x: ref a); 


ПРИМЕЧАНИЕ 

Синтаксис необлзателвнмх и именованнмх параметров в C# весвма удобен при 
написании кода, поддерживакнцего обЂектнук) моделЂ СОМ из Microsoft Office. 
При Bbi30Be СОМ-компонентов C# позволлет опускатЂ клкзчевме слова ref/out 
в процессе передачи аргументов по ссЂшке. Зто еш,е болЂше упро 1 дает код. Если 
же СОМ-компонент не вшв 1 ваетсл, наличие рлдом с аргументом клкзчевого слова 
ref/out облзателвно. 


Атрибут DefaultParameterValue 
и необлзателвнме атрибутм 

ХотелосБ бм, чтобм концепцич заданнмх по умолчаншо и необизателћнмх аргумен- 
тов вБгходила за пределБ1 С#. Особенно здорово 6бшо 6бц если 6бг программистБ1 
могли определнтБ методБ1, указБ1вак)гцие, какие параметрБ1 mh.tmiotcm необиза- 
телвнБши и каковБ1 должнб1 6б1тб заданнБ1е по умолчаниго значенин параметров 
в разнБ1х нзБ1ках программировантш, дав попутно возможностб вБ 13 Б 1 ватБ их из 
разнБ1х НЗБ1КОВБ1Х сред. Но такое возможно толбко при условии, что ввтбраннБш 
компилитор позволиет при вБ 130 ве опускатв некоторБШ аргументБ1, а также умеет 
определитБ заданнБ1е по умолчаниго значенгш зтттх аргументов. 

В C# параметрам со значением по умолчаниго назначаетсл настраиваемвш 
атрибут System . Runtime . InteropServices . OptionalAttribute, сохранигогцииси 
в метаданнБ 1 х итогового фаила. Кроме того, компилнтор применнет к параметру 
атрибут System . Runtime . InteropServices . DefaultParameterValueAttribute, 
опнтб же сохрании его в метаданнБ 1 х итогового фаила. После чего конструктору 
DefaultParameterValueAttribute передаготсн iiocTOMiiiibie значенгш, указаншле 
в первоначалвном коде. 

В итоге встречаи код, вБ13Б1вагогции метод, в котором не хватает аргументов, 
компилнтор провериет, нвлиготси ли зти аргументБ1 необизателБНБ1ми, берет их 
значенгш из метаданннтх и автоматически вставлиет в вбтзов метода. 


Нелвно типизированнме 
локалБнне переменнме 


В C# поддерживаетсл возможностб определенил типа исполБзуеммх в методе ло- 
калвнмх переменнмх по типу исполБзуемого при их инициализации вБфаженил: 
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private static void ImplicitlyTypedLocalVariables() { 
var name = "Deff"; 

ShowVariableType(name); // Внвод: System.String 

// var n = null; // Ошибка 

var х = (String)null; // Допустимо, хотл и бесполезно 

ShowVariableType(x) ; // Вшвод: System.String 

var numbers = new Int32[] { 1, 2, 3, 4 }; 

ShowVariableType(numbers); // Вшвод: System.Int32[] 

// МенБше символов при вводе сложншх типов 

var collection = new Dictionary<Stringj Single>() { { "Grant"j 4.0f } }; 

// Вшвод: System.Collections.Generic.Dictionary'2[System.String,System.Single] 
ShowVariableType(collection); 
foreach (var item in collection) { 

// Вшвод: System.Collections.Generic.KeyValuePair'2 
[System.Stringj System.Single] 

ShowVariableType(item); 

} 

} 

private static void ShowVariableType<T>(T t) { 

Console.WriteLine(typeof(T)); 

} 

Перван строка кода метода ImplicitlyTypedLocalVariables вводит новуго ло- 
калБнуго переменнуго при помоти клгочевого слова var. Чтобм определитБ ее тип, 
компиллтор смотрит на тип вБфаженин с правои сторонБ 1 от оператора присваивашш 
(=). Так как "Jeff " — зто строка, компшштор присваивает переменнои name тип 
String. Что6б1 доказатБ, что компилнтор правилБно определнет тип, н написал уни- 
версалБНБш метод ShowVariableType. Он определлет тип своего аргумента и вбшодит 
его на консолб. Длн простотБ 1 чтенин вбшодимбш методом ShowVariableType значе- 
Н 1 ш н добавил в виде комментариев внутрБ метода ImplicitlyTypedLocalVariables. 

Вторан операцин присваиванин (закомментированнач) в методе ImplicitlyType- 
dLocalVariables во времн компилиции привела 6bi к ошибке (ошибка CS0815: 
невозможно присвоитБ значение null локалБнои переменнои с неивно заданнБш 
типом): 

error CS0815: Cannot assign <null> to an implicitly-typed local variable 

Дело в том, что значение null неивно приводитсл к лгобому ссБшочному типу 
или значимому типу, допускагогцему значение null. Соответственно, компилнтор 
не в состоннии однозначно определитБ его тип. Однако в третБеи операции при- 
сваиванил н показал, что инициализироватБ локалБнуго переменнуго с нелвно 
заданнБш типом значением null все-таки можно, если в нвном виде указатв тип 
(в моем примере зто тип String). Впрочем, зто не саман полезнан возможностб, так 
как, написав String х = null; , bbi получите тот же самБш резулБтат. 
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В четвертом примере в полнои мере демонстрируетсн полезностБ локалБнмх 
переменнмх неивно заданного типа. ВедБ без зтои возможности вам бм потребова- 
лосб с обеих сторон от оператора присваивангш писатБ Dictionary<Stning, Single>. 
Зто не просто увеличивает обвем набираемого текста, но и заставлнет редактироватБ 
код с обеих сторон от оператора присваивангш в случае, если вм решите поменнтћ 
тип коллекции или лгобои из типов обобгценнмх параметров. 

В цикле foreach и также восполБЗОвалсн клгочевмм словом var, заставив 
компилнтор автоматически определитБ тип злементов коллекции. Зтот пример 
демонстрирует полћзу клгочевого слова var внутри инструкции foreach, using 
и for. Кроме того, оно полезно в процессе зкспериментов с кодом. К примеру, 
вм инициализируете локалБнуго переменнуго с ненвно заданнмм типом, взнв за 
основу тип возврагцаемого методом значешш. Но в будугцем может поивитмш не- 
обходимостБ поменнтБ тип возврагцаемого значенгш. В зтом случае компилитор 
автоматически определит, что тип возврагцаемого методом значенгш изменилси, 
и изменит тип локалвнои переменнои! К сожалениго, осталннои код внутри ме- 
тода, работагогции с зтои переменнои, может перестатв компилироватБСи — если 
зтот код обрагцаетсл к членам в предположении, что переменнан принадлежит 
к старому типу. 

В Microsoft Visual Studio при наведении указателн мбшш на клгочевое слово 
var поивлнетсл всплвшагогцан подсказка с названием типа, определиемого компи- 
литором. Функциго неивного задангш типа локалБНБ 1 х переменнБ 1 х в C# следует 
задеиствоватБприработесметодами, исполБзугогцими aiioiuiMiii.ie tiiiii.i. Они под- 
робно рассматривагот в главе 10. 

Тип параметра метода при помогци клгочевого слова var о 6 бнвлнтб нелБЗн. ВедБ 
компилнтор будет определлтп его, исходи из типа аргументов, передаваемБ 1 х при 
вБ130ве метода. Bi.isona же может вообгце не 6bitb или же, наоборот, их может 6 б 1 тб 
несколБКО. Аналогично, пе.њзи о 6 бнвлнтб при помогци зтого клгочевого слова тип 
по./ш. Длл такого ограниченгш в C# сугцествует множество причин. Одна из них — 
возможностб обрагценин к полго из несколкких методов. Группа проектировашш C# 
считает, что контракт (тип переменнои) должен 6 б 1 тб указан нвно. Второи причинои 
нвлнетсл тот факт, что в данном случае aiioiniMiii.ie типб 1 (обсуждаемБге в главе 10) 
начнут вб 1 ходитб за границБ1 одного метода. 

ВНИМАНИЕ 

Не путаите lononeBbie слова dynamic и var. Обилвление локалинои переменнои с клкз- 
чевмм словоуаглвллетсл не болеечем синтаксическим сокрашением, заставллкнцим 
компиллтор определитБ тип даннмх по вмражени 10 . Данное клкзчевое слово служит 
толбко длл обвлвленил локалБНБ 1 х переменнмх внутри метода, в то времл как клкз- 
чевое слово dynamic исполБзуетсл длл локалБнмх переменнБ 1 х, полеи и аргументов. 
Невозможно привести вмражение к типу var, но такал операцил вполне допустима 
длл типа dynamic. ПеременнБ 1 е, обБлвленни 1 е с клк>чевБ 1 м словом var, должнм ини- 
циализироватБСл лвно, что не облзателБно длл переменнмх типа dynamic. Более 
подробнукз информацикз о динамическом типе вм наидете в главе 5. 
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Передача параметров в метод по ссБшке 

По умолчаниго CLR предполагает, что все параметрм методов передаготси по 
значешио. При передаче обпекта ссмлочного типа методу передаетси ссмлка (или 
указателћ) на зтот обпект. То ссг i> метод может изменитћ переданнми обпект, влгшн 
на состолние вмзмвакзгцего кода. Если параметром нвллетси зкземплир значимого 
типа, методу передаетсл его копин. В зтом случае метод получает собственнуго 
копиго обпекта, а исходнми зкземплнр сохраннетси неизменнмм. 

ВНИМАНИЕ 

Следует знатБ тип каждого обиекта, передаваемого методу в качестве параметра, 
посколику манипулируклции параметрами код может суидественно различатвса в за- 
висимости от типа параметров. 


CLR также позволлет передаватБ параметрБг по сспшке, а не по значениго. В C# 
зто делаетси с помогцбго клгочевБгх слов out и ref . Оба заставлигот компилнтор 
генерироватБ метаданнБде, описБгвагогцие параметр как переданнвш по ссндлке. 
Компилнтор исполБзует зти метаданнБге длл генерировашш кода, передагогцего 
вместо самого параметра его адрес. 

С точки зренин CLR, клгочеввге слова out и ref не различаготсн, то еств длн них 
генерируготси одинаковБги IL -код, а метаданнБге отличаготсн всего одним битом, 
указБшагогцим, какое клгочевое слово 6бшо исполБЗОвано при обБнвлении метода. 
Однако компшштор C# различает зти клгочеввге слова при ввгборе метода, исиолб- 
зуемого дли инициализации обиекта, на которБнг указишает переданнаи ссишка. 
Если параметр метода помечен клгочевкш словом out, вБШБшагогции код может не 
инициализироватБ его, пока не вБгзван сам метод. В зтом случае вБгзваннБш метод 
не может прочитати значение параметра и должен записати его, прежде чем вернути 
управление. Если же параметр помечен клгочеввш словом ref , вБгзвшагогции код 
должен инициализироватБ его перед вбгзовом метода, а вБгзваннБш метод может 
как читатБ, так и записБшатБ значение параметра. 

Поведение ссбшочибгх и значимБгх типов при исполБЗОвании клгочеввгх слов out 
и ref различаетсн значителБно. Вот как ото вбгглидит в случае значимого типа: 

public sealed class Program { 
public static void Main() { 

Int32 х; // ИнициализациА х 

GetVal(out х); // Инициализацин х не облзателцна 

Console.WriteLine(x); // Виводитсн 10 

} 

private static void GetVal(out Int32 v) { 

v = 10; // Зтот метод должен инициализироватц переменнук) V 

} 

} 
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Здесћ переменнан х обЂнвлена в стеке Main, а ее адрес передаетсл методу GetVal. 
Параметр зтого метода v представллет собои указателЂ на значимми тип Int32. 
Внутри метода GetVal значение типа Int32, на которое указмвает v, изменнетсл 
на 10. Именно зто значение вмводитсн на консолђ, когда метод GetVal возврагцает 
управление. ИсполБЗОвание клгочевого слова out со значиммми типами повмшает 
зффективностБ кода, так как предотврагцает копирование зкземплирнБ 1 х полеи 
значимого типа при вБИОвах методов. 

А теперв рассмотрим аналогичнБ1и пример с клгочевнш словом ref : 

public sealed class Program { 
public static void Main() { 

Int32 х = 5; // Инициализацил х 

AddVal(ref х); // х требуетсл инициализироватц 

Console.WriteLine(x); // Виводитсл 15 

} 

private static void AddVal(ref Int32 v) { 

v += 10; // Зтот метод может исполцзоватц инициализированнми параметр v 

} 

} 

Здесв обБнвленнои в стеке Main переменнои х присваиваетсл началвное значе- 
ние 5. Затем ее адрес передаетсл методу AddVal, параметр v которого представлиет 
собои указателв на значимвш тип Int32 в стеке Main. Внутри метода AddVal должно 
6 б 1 тб уже инициализированное значение типа Int32, на которое указвшает пара- 
метр v. Таким образом, метод AddVal может исполБЗОватБ первоначалБное значение v 
в лгобом вБфажении. Он может меннтБ зто значение, возврагцан ввгоБшагогцему коду 
новБпт вариант. В рассматриваемом примере метод AddVal прибавлнет к исходному 
значениго 10. Соответственно, когда он возврагцает управленне, переменнан х метода 
Main содержит значение 15, которое и вбшодитсн на консолб. 

В завершение отметим, что с точки зренгга IL или CLR клгочеввге слова out 
и ref ничем не различаготсн: оба заставлигот передатв указателБ на зкземплнр о 6 б- 
екта. Разница в том, что они помогагот компшгатору гарантироватв корректностБ 
кода. В следугогцем коде попБ 1 тка передатБ методу, ожидагогцему параметр ref , не- 
инициализированное значение приводит к ошибке компилнции (ошибка CS0165: 
исполвзование локалвнои переменнои х, у которои не задано значение): 

error CS0165: Use of unassigned local variable 'х' 

A вот сам фрагмент кода, ввгоБшагогции зто сообгцение: 

public sealed class Program { 
public static void Main() { 

Int32 х; // х не инициализируетсн 

// Следунлцан строка не компилируетсн, а виводитсл сообшение: 

// error CS0165: Use of unassigned local variable 'х' 

AddVal(ref х); 

Console.WriteLine(x); 

} 

private static void AddVal(ref Int32 v) { 
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v += 10; // Зтот метод может исполвзоватв инициализированнми параметр v 

} 

} 


ВНИМАНИЕ 

Менл часто спрашивакзт, почему при внзовах методов в программах на C# надо в чвном 
виде указиватц KaioneBbie слова out или ref. В конце концов, компилнтор в состолнии 
самостолтелино определити, какое из клкзчевмхслов емутребуетсл, азначит, должен 
корректно компилировати код. Однако разработчики C# сочли, что вмзмва 10 шии код 
должен лвно указмватв свои намеренил, чтобм при вмзове метода сразу бмло лсно, 
что зтот метод должен менлти значение передаваемои переменнои. 

Кроме того, CLR позволлет по-разному перегружати методм в зависимости от 
вмбора параметра out или ref. Например, следукдции код на C# вполне допустим 
и прекрасно компилируетсл: 

public sealed class Point { 

static void Add(Point p) { ... } 
static void Addfref Point p) { ... } 

} 

He допускаетсл перегружаљ методм, отличакшдиесл толвко типом параметров (out 
или ref), так как резулвтатом их JIT -компиллции становитсл идентичнми код мета- 
даннмх, представллк)ш 1 их сигнатуру методов. Позтому в показанном ранее типе Point 
л не могу определити воттакои метод: 

static void Add(out Point p) { ... } 

При попмтке BKniOHHTb такои метод в тип Point компиллтор C# вернет ошибку (ошибка 
CS0663: в 'Add' нелизл определлти перегруженнмх методов, отличнмх от ref и out): 

error CS0663: 'Add' cannot define overloaded methods that differ only 
on ref and out 

Co значимБши типами клгочевБге слова out и ref дагот тот же резулћтат, что 
и передача ссбшочного типа по значениго. Они позволигот методу управллтв 
единственнБш зкземплиром значимого типа. ВБТЗБГвагохции код должен вввделитБ 
памнтБ дли зтого зкземплира, а вБгзваннБпг метод управлиет вввделеннои памитБГО. 
В случае ссбшочнбгх типов вБ13Бшагогции код вБвделиет памитБ дли указателл на 
передаваемБш обвект, а вБгзваннБпг код управлнет зтим указателем. В силу зтих 
особенностеи исполвзование клгочеввгх слов out и ref со ссбшочнбши типами по- 
лезно, лишб когда метод собираетсн «вернутБ» ссбшку на известнкш ему обвект. 
Рассмотрим зто на примере: 

using System; 
using System.IO; 

public sealed class Program { 
public static void Main() { 

FileStream fs; // Обцект fs не инициализирован 

// Первми фаил открмваетсл длл обработки 

продолжение & 
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StartProcessingFiles(out fs); 

// Продолжаем, пока остакзтсл фаилш длл обработки 
for (; fs != null; ContinueProcessingFiles(ref fs)) { 

// Обработка фаила 
fs.Read(...); 

} 


private static void StartProcessingFiles(out FileStream fs) { 
fs = new FileStream(...); // в зтом методе обБект fs 

// должен инициализироватисл 


} 


private static void ContinueProcessingFiles(ref FileStream fs) { 
fs.Close(); // Закрмтие последнего обрабатшаемого фаила 


// OTKpbiTb следукиции фаил или вернути nullj если фаилов болише нет 
if (noMoreFilesToProcess) fs = null; 
else fs = new FileStream (...); 

} 

} 

Как видите, главнаи особенностБ зтого кода в том, что методБ1 с параметрами 
ссбшочного типа, помеченнБши клкзчевБши словами out или nef, создагот обвект 
и возврагцагот ввгоБшагогцему коду указателк на него. Обратите внимание, что метод 
ContinueProcessingFiles может управлнтв передаваемБш ему обвектом, прежде 
чем вернет hobbih обвект. Зто возможно благодарн тому, что его параметр помечен 
клгочеввш словом ref . Показаннвш здесБ код можно немного упроститн: 

using System; 
using System.IO; 

public sealed class Program { 
public static void Main() { 

FileStream fs = null; // ОблзателБное присвоение 
// началБного значенил null 


// Открмтие первого фаила длл обработки 
ProcessFiles(ref fs); 

// Продолжаем, пока остакзтсл необработаннме фаилш 
for (; fs != null; ProcessFiles(ref fs)) { 

// Обработка фаила 
fs.Read(...); 

} 

} 

private static void ProcessFiles(ref FileStream fs) { 
// Если предшдушии фаил открмт, закршваем его 
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if (fs != null) fs.Close(); // Закрмтв последнии обрабатмваемми фаил 

// OTKpbiTb следукпции фаил или вернутБ nullj если фаилов болише нет 
if (noMoneFilesToProcess) fs = null; 
else fs = new FileStream (...); 

} 


Етце один пример, демонстрирукдции исполћзование клгочевого слова ref длл 
реализации метода, меннгогцего местами два ссмлочнмх типа: 

public static void Swap(ref Object a, ref Object b) { 

Object t = b; 
b = a; 
a = t; 

} 

Кажетси, что код, меннгогции местами ссмлки на два обвекта типа String, дол- 
жен вмглидетБ так: 

public static void SomeMethod() { 

String sl = "Deffrey"; 

String s2 = "Richter"; 

Swap(ref sl, ref s2); 

Console.WriteLine(sl); // Вмводит "Richter" 

Console.WriteLine(s2); // Вмводит "Deffrey" 

} 

Однако компилироватБСи зтот код не будет: ведн переменнБ1е, передаваемБШ 
методу по ссБшке, должнб1 6б1тб одного типа, обБнвленного в сигнатуре метода. 
Иначе говорц, метод Swap ожидает получитв ссбшки на тип Object, а не на тип 
String. Решение же нашеи задачи вбшлндит следугогцим образом: 

public static void SomeMethod() { 

String sl = "Deffrey"; 

String s2 = "Richter"; 

// Тип передаваемшх по ссмлке переменншх должен 
// соответствовати ожидаемому 
Object ol = sl, о2 = s2; 

Swap(ref ol, ref o2); 

// Приведение обБектов к строковому типу 
sl = (String) ol; 
s2 = (String) o2; 

Console.WriteLine(sl); // Вмводит "Richter" 

Console.WriteLine(s2); // Вмводит "Deffrey" 

} 

Такаи версин метода SomeMethod будет компгшироватБСц и работатБ нужнБгм 
нам образом. Причинои ограниченгш, которое нам пришлоск обходитБ, нвлнетсл 
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обеспечение безопасности типов. Вот пример кода, нарушагошего безопасностБ 
типов (к счастћго, он не компилируетсл): 

internal sealed class SomeType { 
public Int32 m_val; 

} 

public sealed class Program { 
public static void Main() { 

SomeType st; 

// Следуклцап строка вудает ошибку CS1503: Argument 'l': 

// cannot convert from 'ref SomeType' to 'ref object'. 

GetAnObject(out st); 

Console.WriteLine(st.m_val); 

} 

private static void GetAnObject(out Object o) { 
o = new String('X'j 100); 

} 

} 

Совершенно исно, что здесв метод Main ожидает от метода GetAnObject обвект 
SomeType. Однако посколкку в сигнатуре GetAnObject задана ссвшка на Object, 
метод GetAnObject может инициализироватБ параметр о обвектом произволБного 
типа. В зтом примере параметр st в момент, когда метод GetAnObject возврагцает 
управление методу Main, ссвшаетсл на обвект типа Stning, в то времн как ожида- 
етсл тип SomeType. Соответственно, вбгоов метода Console .WniteLine закончитсн 
неудачеи. Впрочем, компилитор C# откажетсл компилироватв зтот код, так как st 
представллет собои ссвшку на обвект типа SomeType, тогда как метод GetAnObject 
требует ссБшку на Object. 

Однако, как оказалоск, зти методБ1 можно заставитБ работатБ при помогци обоб- 
гцении. Вот так следует исправитБ показаннБП! ранее метод Swap: 

public static void Swap<T>(ref T a, ref T b) { 

T t = b; 
b = a; 
a = t; 

} 

После зтого следугогции код (идентичнБп) ранее показанному) будет без проблем 
компилироватБСн и вбшолннтбси: 

public static void SomeMethod() { 

String sl = "3effrey"; 

String s2 = "Richter"; 

Swap(ref sl, ref s2); 

Console.WriteLine(sl); // Вшводит "Richter" 

Console.WriteLine(s2); // Вшводит "3effrey" 

} 
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За другими примерами решенин, исполБзугогцими обобгценин, обрагцаитесБ к 
классу System . Threading . Interlocked с его методами CompareExchange и Exchange. 


Передача переменного количества 
аргументов 

Иногда разработчику удобно определитБ метод, способнБш приниматБ переменное 
число параметров. Например, тип System.String предлагает методБг, вбшолннго- 
гцие обБединение произволБного числа строк, а также методБц при вБгзове которвгх 
можно задатв набор единообразно форматируемнгх строк. 

Метод, принимагогции переменное число аргументов, о6бнвлнгот так: 

static Int32 Add(params Int32[] values) { 

// ПРИМЕЧАНИЕ: при необходимости зтот массив 
// можно передатБ другим методам 

Int32 sum = 0; 
if (values != null) { 

for (Int32 х = 0; х < values.Length; x++) 
sum += values[x]; 

} 

return sum; 

} 


Незнакомвш в зтом методе нвллетсл толбко клгочевое слово params, примененное 
к последнему параметру в сигнатуре метода. Если не обрагцатв на него внимашш, 
станет лсно, что метод принимает массив значении типа Int32, складвшает все 
злементвг зтого массива и возврагцает полученнуго сумму. 

Очевидно, зтот метод можно ввгзватв так: 

public static void Main() { 

// BblBOflHT "15" 

Console.WriteLine(Add(new Int32[] { 1, 2, 3, 4, 5 } )); 

} 

He вБ 13 Бшает сомнении утверждение, что зтот массив легко инициализироватв 
произволБНБш числом злементов и передатв длл обработки методу Add. Показан- 
нбш здесБ код немного неуклгож, хотл он корректно компилируетсн и работает. 
Разработчики, конечно, предпочли 6ki вбгобшдтб метод Add так: 

public static void Main() { 

// BblBOflHT "15" 

Console.WriteLine(Add(lj 2, 3, 4, 5)); 

} 

ТакаиформавБгзовавозможнаблагодарнклгочевому слову params. Именно оно 
заставлнет компшштор рассматриватв параметр как зкземплир настраиваемого 
атрибута System.ParamArrayAttribute. 
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Обнаружив такои вмзов, компилитор C# проверлет все методм с заданнмм име- 
нем, у котормх ни один из параметров не помечен атрибутом РагатАггау. Наидл 
метод, способнми приннтв вмзов, компилитор генерирует вмзмвагогции его код. 
В противном случае игцутси методм с атрибутом РагатАггау и проверлетсл, могут 
ли они приннтБ вмзов. Если компилнтор находит подходнгции метод, то прежде чем 
сгенерироватБ код его вмзова, он генерирует код, создагогции и заполннгогции массив. 

В предмдугцем примере не определен метод Add, принимагогции пнтб совмести- 
ммх с типом Int32 аргументов. Компилнтор же видит в тексте исходного кода вмзов 
метода Add, которому передаетсл список значении Int32, и метод Add, у которого 
массив типа Int32 помечен атрибутом РагатАггау. Компилитор считает даннми 
метод подходнгцим длн вмзова и генерирует код, собирагогции все параметрм в мас- 
сив типа Int32 и вмзмвагогции метод Add. В конечном итоге получаетсл, что можно 
написатБ вмзов, без труда передагогции методу Add набор параметров, и компили- 
тор сгенерирует тот же код, что и длл первои версии вмзова метода Add, в которои 
массив создаетсл и инициализируетсл нвно. 

Клгочевмм словом params может 6мтб помечен толбко последнии параметр 
метода (ParamArrayAttribute). Он должен указмватћ наодномернми массив про- 
изволбного типа. В последнем параметре метода допустимо передаватћ значение 
null или ссмлку на массив, состошции из нули злементов. Следугогции вмзов ме- 
тода Add прекрасно компилируетсл, отлично работает и дает в резулћтате сумму, 
равнуго 0 (как и ожидалосћ): 


public static void Main() { 

// Обе строчки виводлт "0" 
Console.WriteLine(Add( )); 
Console.WriteLine(Add(null)); 


} 


// передает новми злемент Int32[0] методу Add 
// передает методу Add значение null, 

// что более зффективно (не вуделлетсл 
// памлтн под массив) 


Все показаннме до сих пор примерм демонстрировали методм, принимагогцие 
произволБное количество параметров типа Int32. А как написатћ метод, принима- 
гогции произволБное количество параметров лгобого типа? Ответ прост: достаточно 
отредактироватБ прототип метода, заставив его вместо Int32 [ ] приниматБ Object [ ]. 
Следугогции метод вбшодит значенгш Туре всех переданнБ 1 х ему обвектов: 

public sealed class Program { 
public static void Main() { 

DisplayTypes(new Object(), new Random(), "leff", 5); 

} 


private static void DisplayTypes(params Object[] objects) { 
if (objects != null) { 

foreach (Object o in objects) 

Console.WriteLine(o.GetType()); 

} 

} 

} 
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При вмполнении зтого кода будет вмведен следугогции резулћтат: 

System.Object 

System.Random 

System.String 

System.Int32 


ВНИМАНИЕ 


Bbi30B метода, принимакхцего переменное число аргументов, снижает производи- 
TenbHOCTb, если, конечно, не передаваљ в лвном виде значение null. В лкзбом случае 
всем обвектам массива нужно вмделитв место в куче и инициализироватвзлементм 
массива, а по завершении работи занлтал массивом памлтв должна 6biTb очиш,ена 
сборидиком мусора. Чтобн уменвшитв негативное влилние зтих операции на про- 
изводителвноств, можно определити несколико перегруженнв 1 х методов, в котормх 
не исполизуетсл клкзчевое слово params. За примерами обратитеси к методу Concat 
класса System.String, котории перегружен следукицим образом: 


public sealed class String : Object, 
public static string Concat(object 
public static string Concat(object 
public static string Concat(object 
public static string Concat(params 


... { 
arg@)j 

arg0j object argl); 
arg@j object arglj object 
object[] args)j 


arg2); 


public static 
public static 
public static 
str3); 

public static 

} 


string Concat(string 
string Concat(string 
string Concat(string 

string Concat(params 


str@j string strl); 

str@j string strlj string str2) 

str@j string strlj string str2j 

string[] values); 


string 


Как видите, длл метода Concat определенн несколико вариантов перегрузки, в ко- 
Topbix клкочевое слово params не исполвзуетсл. Здеси представлени наиболее рас- 
пространенни 1 е вариантн перегрузки, которне, собственно, и предназначенм длл 
повншенил зффективности работм в стандартних ситуацилх. Вариантн перегрузки 
с клкзчевмм словом params предназначенм дпл более редких ситуации, посколвку 
при зтом страдает производителвноств. К cnacTbio, такие ситуации возникакот не 
такужчасто. 


Тигњ1 параметров 
и возвраш;аемБ1х значении 

06ђлвллц тип параметров метода, нужно по возможности указмватЂ <<минималЂнме» 
типм, предпочитан интерфеисм базовмм классам. Например, при написании метода, 
работагогцего с набором злементов, лучше всего о6ђнвитђ параметр метода, исполђ- 
зуи интерфеис IEnumerable<T> вместо силђного типа даннмх, например List<T >, 
или егце более силђного интерфеисного типа ICollection<T > или IList<T>: 
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// Рекомендуетсл в зтом методе исполвзоватв параметр слабого типа 
public void ManipulateItems<T>(IEnumerable<T> collection) { ... } 

// He рекомендуетсл в зтом методе исполвзоватв параметр силбного типа 
public void ManipulateItems<T>(List<T> collection) { ... } 

Причина, конечно же, в том, что первми метод можно вмзмватБ, передав в него 
массив, обвект List<T>, обвект Stning и т. п., то естБ лкзбои обвект, тип которого 
реализует интерфеис IEnumerable<T>. Второи метод принимает толбко обвектБ1 
List<T>, с массивами или обвектами Stning он работатв уже не может. Испо, что 
первБш метод предпочтителБнее, так как он гибче и может исполБЗОватБСн в более 
разнообразнБ1х ситуацинх. 

Естественно, при создании метода, получакзгцего список (а не просто лкзбои 
перечислимвп! обвект), нужно о6бнвлитб тип параметра как I List<T>, в то времи 
как типа List<T> лучше избегатв. Именно такои подход позволит вБИБшакзгцему 
коду передаватБ массивБ 1 и другие обЂектБц тип которБ 1 х реализует I List<T>. 

Обратите внимание, что в приводимБ1х примерах речБ идет о коллекцгшх, соз- 
даннБ 1 х с исполБЗОванием архитектурБ 1 интерфеисов. Зтот же подход применим 
к классам, опиракзгцимсл на архитектуру базоввгх классов. Потому, к примеру, при 
реализации метода, обрабатвшакзгцего баитБ1 из потока, пишем следукзгцее: 

// Рекомендуетсл в зтом методе исполБЗОватБ параметр мвгкого типа 
public void ProcessBytes(Stream someStream) { ... } 

// He рекомендуетсл в зтом методе исполБЗОватБ параметр силбного типа 
public void ProcessBytes(FileStream fileStream) { ... } 

ПервБ1и метод может обрабатБшатБ баитБ1 из потока лкзбого вида: FileStneam, 
NetworkStneam, MemonyStneam и т. п. Второи поддерживает толбко FileStneam, 
то естБ областБ его примененин ограничена. 

В то же времи, о6ђивлии тип возврагцаемого методом обвекта, желателвно 
ББгбиратБ самБпг силбнбш из доступнБ 1 х вариантов (|њп аж:м> не ограничиватвсл 
конкретнБ1м типом). Например, лучше о6ђнвлнтб метод, возврагцакзгции обвект 
FileStream, а не Stneam: 

// Рекомендуетсл в зтом методе исполБЗОватБ 
// cn^bHbin тип возвратаемого обБекта 
public FileStream OpenFile() { ... } 

// Не рекомендуетсв в зтом методе исполБЗОватв 
// слабни тип возвра[цаемого обБекта 
public Stream OpenFile() { ... } 

Здесв предпочтителБнее первБш метод, так как он позволиет ввиБшакзгцему коду 
обрагцатБСн с возврагцаемБш обвектом как с обвектом FileStneam или Stneam. А вот 
второму методу требуетсл, чтобвг вБгзБшагогции код рассчитБшал толбко на обљект 
Stneam, то естБ областБ его примененгш более ограничена. 

Иногда требуетсл сохранитБ возможностб изменнтБ внутреннгокз реализацикз 
метода, не влгшн на вБгзБшагогции код. В приведенном ранее примере изменение 
реализацгш метода OpenFile в будугцем маловеронтно, он врнд ли будет возвра- 
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тцатБ что-либо отличное от обЂекта типа FileStream (или типа, производного от 
FileStream). Однако длн метода, возврагцакнцего обвект List<String>, вполне воз- 
можно изменение реализации, после которого он начнет возврагцатЂ тип String [ ]. 
В подобнмх случалх следует вмбиратБ более слабми тип возврагцаемого обвекта. 
Например: 

// Гибкии вариант: в зтом методе исполвзуетсв 

// млгкии тип возврашаемого обвекта 

public IList<String> GetStringCollection( ) { ... } 

// Негибкии вариант: в зтом методе исполвзуетсл 

// cn^bHbin тип возврацаемого обБекта 

public List<String> GetStringCollection() { ... } 

Хотл в коде метода GetStringCollection исполБзуетсл и возврагцаетсл о 6 ђ- 
ект List<String>, в прототипе метода лучше указатв в качестве возврагцаемого 
обвекта I List<String>. Даже если в будугцем указаннан в коде метода коллекции 
изменит свои тип на String [ ], вмзмвакнции код не потребуетсл ни редактироватв, 
ни даже перекомпилироватЂ. Обратите внимание, что в зтом примере н вмбрал са- 
мми «силђнми» из саммх «слабмх» типов. К примеру, н не восполЂЗОвалсн типом 
IEnumerable<String> или ICollection<String>. 


КонстантностБ 

В некотормх измках, в том числе в неуправлиемом нзмке С++, методм и параме- 
трм можно о6ђнвлитђ как константм. Зтим вм запрегцаете коду в зкземплнрном 
методе изменнтв полл обвекта или обЂектм, передаваемме в метод. В CLR зта 
возможностђ не поддерживаетсл, а многим программистам ее не хватает. Так как 
сама исполннкнцан среда не поддерживает такои функции, естественно, что она не 
поддерживаетсн ни в одном измке (в том числе в С#). 

В первуго очередв следует заметитЂ, что в неуправлиемом коде С++ пометка 
зкземплнрного метода или параметра клгочевмм словом const гарантировала не- 
изменноств зтого метода или параметра стандартнмми средствами кода. При зтом 
внутри метода всегда можно бмло написатв код, изменнкшџп! обвект или параметр 
путем игнорировании их «константнои» природм или путем получешш адреса 
обвекта с последугогцеи записвго. В определенном сммсле неуправлиемми код С++ 
«врал» программистам, утверждал, что константнме обЂектм или константнме 
параметрм вообгце пе. њзи меннтв. 

Создаван реализациго типа, разработчик может просто избегатв написанин кода, 
меннгогцего обЂектм и параметрм. Например, неизменнеммми нвлнготсн строки, так 
как класс String не предоставлнет нужнмх длл зтого методов. 

Кроме того, специалистм Microsoft не предусмотрели в CLR возможностђ про- 
верки неизменности константнмх обвектов или константнмх параметров. CLR 
пришлосЂ бм при каждои операции записи проверитЂ, не вмполннетсл ли записв 
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в константнми обвект, что силбно снизило бм зффективностБ работБ 1 программБк 
Естественно, обнаружение нарушенин должно приводитБ к вквдаче исклвзченин. Кро- 
ме того, поддержка констант создает дополнителБНБге сложности длл разработчиков. 
В частности, при наследовании неизменнемого типа производнБ1е типб1 должнб1 
соблгодатБ зто ограничение. Кроме того, неизменнемБш тип, скорее всего, должен 
состолтб из полеи, которБШ тоже представлнгот собои неизменнемБ 1 е типбг 

Зто лишб несколБКО причин, по которкш CLR не поддерживает константнвге 
обвектБ! / аргументБк 
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Зта глава посвнгцена своиствам. Своиства позволнгот обратитћсн к методу в ис- 
ходном тексте программм с исполБЗОванием упрогценного синтаксиса. CLR под- 
держивает два вида своиств: без параметров, их назмвагот просто — свопства, и с 
параметрами — у них в разнмх измках разное название. Например, в C# своиства 
с параметрами назмвагот индексаторами, а в Visual Basic — свопствами no умолчанит. 
Кроме того, в зтои главе рассказмваетси об инициализации своиств при помогци 
инициализаторов обвектов и коллекции, а также о механизме обЂединенгш своиств 
посредством анонимнмх типов и типа System . Tuple. 


Своиства без параметров 

Во многих типах определиетси информацгш состоншш, которуго можно прочитатБ 
или изменитБ. Часто зта информацгш состоннгш реализуетсн полнми типа. Вот, 
например, определение типа с двумл полими: 

public sealed class Employee { 

public String Name; // Имл сотрудника 
public Int32 Age; // Возраст сотрудника 

} 

Создаван зкземплнр зтого типа, можно получитБ или задатБ лгобБге сведенин 
о его состоннии при помогци примерно такого кода: 

Employee е = new Employee(); 

e.Name = "Deffrey Richter"; // Задаем имп сотрудника 
e.Age = 48; // Задаем возраст сотрудника 

Console.WriteLine(e.Name); // Виводим на зкран "3effrey Richter" 

Зтот способ чтенгш и записи информации состоингш обвекта оченв распро- 
странен. Однако и считаго, что реализацгш такого вида совершенно недопустима. 
Одним из краеуголБНБгх камнеи обЂектно-ориентированного программировангш 
и разработки нвлиетсл инкапсуллцил данних. Инкапсулнцгш даннвгх означает, что 
полн типа ни в коем случае не следует открвгватБ дли обгцего доступа, так как в зтом 
случае слишком просто написатБ код, спосо6нбш испортитБ сведенгш о состопнии 
обвекта путем ненадлежагцего исполвзовангш полеи. Например, следугогцим кодом 
разработчик может легко повредитв обЂект Employee: 


e.Age = -5; // Можете вообразитБ человека, которому минус 5 лет? 
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Естб и другие причинБ1 дли инкапсулиции доступа к полнм даннБ1х типа. До- 
пустим, вам нужен доступ к iio.tio, что6б1 что-то сделатБ, разместитБ в k.'hiic неко- 
торое значение или создатв какои-то внутреннии обвект, создание которого 6бшо 
отложено, причем обрагцение к полго не должно нарушатк безопасностБ потоков. 
Или, скажем, поле нвлнетсл логическим и его значение представлено не баитами 
в памнти, а вБшисллетсл по некоторому алгоритму. 

Каждал из зтих причин заставлнет при разработке типов, во-перввгх, помечатБ 
все ilo.ia как закрБ1ТБ1е (private), во-вторБ1х, даватБ полБЗОвателго вашего типа 
возможностб полученгш и заданин сведении о состоннии через cneuna. ; ii,iii.ie мето- 
дб1, предназначеннБШ исклгочителБно длн зтого. МетодБц вБшолннгогцие функции 
оболочки длл доступа к полго, обкшно назБшагот методами доступа (accessor). 
МетодБг доступа могут вбшолнитб дополнителБНБге проверки, гарантирул, что 
сведенгш о состоинии обвекта никогда не будут искаженБк И переписал класс из 
предБвдушего примера следуговдим образом: 

public sealed class Employee { 

private String m_Name; // Поле стало закрутмм 

private Int32 m_Age; // Поле стало закршт, 1 м 

public String GetName() { 
return(m_Name); 

} 

public void SetName(String value) { 
m_Name = value; 

} 

public Int32 GetAge() { 
return(m_Age); 

} 

public void SetAge(Int32 value) { 
if (value < 0) 

throw new ArgumentOutOfRangeException("value", value.ToString(), 

"The value must be greater than or equal to 0"); 
m_Age = value; 

} 

} 

Несмотрн на всго простоту, зтот пример демонстрирует огромное преимугцество 
инкапсулнции полеи даннвгх. Он также показБшает, как просто создаготсл своиства, 
доступнвге толбко д./ш чтенгш или толбко длн записи — достаточно опуститк один 
из методов доступа. В качестве алБтернативБг можно позволитб изменнтБ значенгш 
толбко в производнБгх типах — длн зтого метод SetXxx помечаетсн как загцигценнБпг 
(protected). 

Как вгвдите, у инкапсулнции даннвгх естБ два недостатка: во-перввгх, из-за реали- 
зации дополнителБНБгх методов приходитси писатв более длиннбш код, во-вторкгх, 
вместо простои ссбшки на имн полл полБЗОвателлм типа приходитсл вБгзвшатБ 
соответствугогцие методвг: 
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e.SetName("Jeffrey Richter"); // Обновление имени сотрудника 

String EmployeeName = e.GetName(); // Получение возраста сотрудника 
е. SetAge(41) ; // Обновление возраста сотрудника 

е. SetAge(-5) ; // Вмдача исклтченин 

// ArgumentOutOfRangeException 

Int32 EmployeeAge = e.GetAge(); // Получение возраста сотрудника 

Лично ’a считаго зти недостатки незначителћнмми. Тем не менее CLR поддержи- 
вает механизм своиств, частично компенсируклции первми недостаток и полностбкт 
устраникиции второи. 

Следугондии класс функционалБно идентичен предБвдушему, но в нем исполб- 
зуготсн своиства: 

public sealed class Employee { 
private String m_Name; 
private Int32 m_Age; 

public String Name { 
get { return(m_Name); } 

set { m_Name = value; } // Клтчевое слово value 
} // идентифицирует новое значение 

public Int32 Age { 

get { return(m_Age); } 
set { 

if (value < 0) // Клгачевое слово value всегда 

// идентифицирует новое значение 
throw new ArgumentOutOfRangeException("value", value.ToString(), 

"The value must be greater than or equal to 0"); 
m_Age = value; 

} 

} 

} 


Как видите, хотн своиства немного усложннгот определение типа, дополнителв- 
нан работа более чем оправдана, потому что она позволиет писатв код следугогцего 
вида: 


e.Name = "Jeffrey Richter"; 
String EmployeeName = e.Name; 
e.Age = 41; 
e.Age = -5; 

Int32 EmployeeAge = e.Age; 


// "Задатц" имн сотрудника 
// "Получитц" имл сотрудника 
// "Задатц" возраст сотрудника 
// Вброс исклтченил 
// ArgumentOutOfRangeException 
// "Получитц" возраст сотрудника 


Можно считатв своиства «умнБ1ми» полими, то естБ полими с дополнителБнои 
логикои. CLR поддерживает статические, зкземплирнБГО, абстрактнБ1е и вирту- 
алБнвге своиства. Кроме того, своиства могут помечатвсл модификатором доступа 
(см. главу 6 ) и определитБСи в интерфеисах (см. главу 13 ). 

У каждого своиства еств ими и тип (но не void). НелБЗи перегружатБ своиства 
(то еств определнтБ несколБКО своиств с одинаковвши именами, но разниш типом). 
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Определнн своиство, обмчно описмвагот пару методов: get и set. Однако опустив 
метод set, можно определитБ своиство, доступное толбко длл чтенин, а опускаи 
толбко метод get, Mbi получим своиство, доступное толбко длн записи. 

МетодБ1 get и set своиства доволбно часто манипулиругот закрБ1ТБ1м полем, 
определеннБш в типе. Зто поле обвшно назвшагот резервним (backing field). Однако 
методам get и set не приходитсл обрашаткси к резервному полго. Например, тип 
System.Threading.Thread поддерживает своиство Priority, взаимодеиствугошее 
непосредственно с ОС, а обвект Thread не поддерживает поле, храннпдее приоритет 
потока. Другои пример своиств, не имегогцих резервнвгх полеи, — зто неизменнемБге 
своиства, ББшислнемБШ при вБшолнении: длина массива, заканчивагогцегосн нулем, 
или областв прнмоуголБника, заданного ширинои и вбгсотои и т. д. 

При определении своиства компилитор генерирует и помегцает в резулвтируго- 
гции управлнемБпг модулБ следугогцее: 

□ метод get своиства генерируетсл, толбко если длл своиства определен метод 
доступа get; 

□ метод set своиства генерируетсл, толбко если длл своиства определен метод 
доступа set; 

□ определение своиства в метаданнвгх управлиемого модулл генерируетсл всегда. 

Вернемсн к показанному ранее типу Employee. Пргг его компилнцгггг компилнтор 
обнаруживает своиства Name гг Age. Посколвку у обоих естк методБг доступа get гг set, 
компилнтор генерирует в типе Employee четвгре определенгш методов. Резулвтат 
получаетсп такои, как если 6бг тип 6бш исходно написан следугогцим образом: 

public sealed class Employee { 
private String m_Name; 
private Int32 m_Age; 

public String get_Name(){ 
return m_Name; 

} 

public void set_Name(String value) { 

m_Name = value; // Аргумент value всегда идентифицирует новое вначение 

} 

public Int32 get_Age() { 
return m_Age; 

} 

public void set_Age(Int32 value) { 

if (value < 0) { // value всегда идентифицирует новое значение 
throw new ArgumentOutOfRangeException("value", value.ToString(), 

"The value must be greater than or equal to 0"); 

} 

m_Age = value; 

} 
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Компшштор автоматически генерирует имена зтих методов, прибавлнн при- 
ставку get_ или set_ к имени своиства, заданному разработчиком. 

Поддержка своиств встроена в С#. Обнаружив код, пмтагогцииси получитБ или 
задатБ своиство, компилитор генерирует вб130в соответствугогцего метода. Если 
исполћзуемБП! нзб1К не поддерживает своиства напрнмуго, к ним все равно можно 
обратитвси посредством ввгоова нужного метода доступа. Зффект тот же, толбко 
исходнбш текст вб 1 глндит менее злегантно. 

Помимо методов доступа, длн каждого из своиств, определеннБ 1 х в исходном 
тексте, компилнторБ1 генериругот в метаданнБ1Х управлиемого модулл записв 
с определением своиства. Такаи записв содержит несколБКО флагов и тип своиства, 
а также ссбшки на методБ1 доступа get и set. Зта информацин сугцествует лишб 
затем, что6бг свнзатБ абстрактное поннтие «своиства» с его методами доступа. Ком- 
пилиторБг и другие инструментБг могут исполБЗОватБ зти метаданнБге через класс 
System.Reflection . PropertyInfo. И все же CLR не исполвзует зти метаданнБге, 
требун при вБшолнении толбко методкг доступа. 


Автоматически реализуемме своиства 

Если необходимо создатБ своиства длн инкапсулнцгш резервнвгх полеи, то в C# еств 
упрогценнБш синтаксис, назБгваемБпг автоматически реализуемими свопспгвами 
(Automatically Implemented Properties, AIP). Приведу пример длл своиства Name: 

public sealed class Employee { 

// Зто своиство ввлнетсв автоматически реализуеммм 
public String Name { get; set; } 
private Int32 m_Age; 
public Int32 Age { 

get { return(m_Age); } 
set { 

if (value < 0) // value всегда идентифицирует новое значение 
throw new ArgumentOutOfRangeException("value"j value.ToString() л 
"The value must be greater than or equal to 0 "); 
m_Age = value; 

} 

} 

} 


Если вб 1 обБнвите своиства и не обеспечите реализациго методов set и get, то 
компилитор C# автоматически о6бнвит их закрвгтвгми полнми. В данном примере 
поле будет иметБ тип String — тип своиства. И компиллтор автоматически реали- 
зует методвг get_Name и set_Name длн правилБного возврагценгш значенгш из полн 
и назначенгш значенгш полго. 

Вбг спросите, зачем зто нужно, особенно в сравненгш с о6бгчнбш обБнвлением 
строкового полн Name? Между ними еств болБшаи разница. ИсполБЗОвание AIP- 
синтаксиса означает, что вбг создаете своиство. Лгобои программнвш код, имегогции 
доступ к зтому своиству, вБгзвшает методБг get и set. Если вбг позднее решите 
реализоватБ зти методБг самостолтелБно, заменив их реализациго, предложеннуго 
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компилитором по умолчаншо, то код, имекпции доступ к своиству, не нужно будет 
перекомпилироватБ. Однако если о6ђнвитб Name как поле и позднее заменитБ его 
своиством, то весћ программнми код, имегогции доступ к полкз, придетсл переком- 
пилироватБ, посколБку он будет обрагцатБСи к методам своиства. 

Лично мне не нравнтсн автоматически реализуемвге своиства, обвгчно л старагосв 
их избегатБ по несколвким причинам. 

□ Синтаксис обБпвленгш полн может вклгочатв инициализациго, таким образом, 
вб 1 обБпвлнете и инициализируете поле в однои строке кода. Однако нет под- 
ходлгцего синтаксиса длл установки при помогци AIP началвного значенгш. 
СледователБно, необходимо неивно инициализироватБ все автоматически реа- 
лизуемБге своиства во всех конструкторах. 

□ Механизм сериализации на зтапе ввшолненгш сохраниет имн полн в сериали- 
зованном потоке. Имн резервного полн длл AIP определнетсл компилнтором, 
и он может меннтБ зто имн каждБпг раз, когда компилирует код, сводн на нет воз- 
можностб десериализации зкземплнров всех типов, содержагцих автоматически 
реализуемвге своиства. Не исполБзуите зтот механизм длл типов, подлежагцих 
сериализации и десериализации. 

□ Во времн отладки нелвзи установитБ точку останова в AIP -методах set и get, 
позтому вб 1 не сможете легко узнатк, когда приложение получает и задает значе- 
ние автоматически реализуемого своиства. Точки останова можно устанавливатв 
толбко в тех своиствах, которвге программист пишет самостоителвно. 

Также следует знатБ, что при исполБЗОвании AIP своиства должнбг иметБ уровенБ 
доступа длн чтенгш и записи, так как компшштор генерирует методкг set и get. Зто 
разумно, посколБку полн длл чтенгш и записи бесполезнБг без возможности чтенгш их 
значенгш, более того, полн длн чтенгш бесполезнБг, если в них будет хранитвсн толбко 
значение по умолчаниго. К тому же из-за того, что вбг не знаете имени автоматггчески 
генерируемого резервного поли, ваш программнБш код должен всегда обрагцатвсн 
к своиству по имени. И если вбг решите пвно реализоватв один из методов доступа, 
то вам придетсл нвно реализоватв оба метода доступа и при зтом отказатБСн от ис- 
полБЗОвангш AIP. Механизм AIP работает слишком бескомпромиссно. 

Осторожнми подход к определеник> своиств 

Лично мне своиства не нравнтсн и л 6бгл 6бг рад, если 6бг в Microsoft решили убратв 
их поддержку из .NET Framework и сопутствугогцих лзбгков программированин. 
Причина в том, что своиства вбггллдлт как полн, нвлннсб по сути методами. Зто 
порождает немБгслимуго путаницу. СтолкнувшисБ с кодом, которкги вроде 6бг об- 
рагцаетсн к полго, разработчик привБгчно предполагает наличие множества условии, 
которвге далеко не всегда соблгодаготсл, если речв идет о своистве. 

□ Своиства могут 6бгтб доступнБг толбко дли чтенин или толбко длн записи, в то 
времн как полн всегда доступнвг и длл чтенгш, и длн записи. Определи л своиство, 
лучше всего создаватв дли него оба метода доступа (get и set). 
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□ Своиство, нвлнисв по сути методом, может вмдаватБ исклточспил, а при обра- 
шенинм к полим исклгочении не бмвает. 

□ Своиства нелБЗи передаватБ в метод в качестве параметров с клгочевБ1м словом 
out или ref , в частности, следугошии код не компилируетсн: 

using System; 

public sealed class SomeType { 

private static String Name { 
get { return null; } 
set {} 

} 

static void MethodWithOutParam(out String n) { n = null; } 

public static void Main() { 

// При попмтке скомпилироватБ следуклцунт строку 
// компиллтор вернет сообшение об ошибке: 

// error CS0206: А property or indexer тау not 
// be passed as an out or ref parameter. 

MethodWithOutParam(out Name); 

} 

} 

□ Своиство-метод может вбшолннтбсн доволбно долго, в то времи как обрапитши 
к полнм вбшолннготсл моменталБно. Часто своиства применнгот длн синхрони- 
зации потоков, но зто может привести к приостановке потока на неопределенное 
времи, позтому своиства не следует исполвзоватв длн зтих целеи — в такои си- 
туации лучше задеиствоватв метод. Кроме того, если предусмотрен удаленннш 
доступ к классу (например, если он наследует от System .MarshalByRefObject), 
ВБ 130 В своиства-метода ввшолннетсн оченн медленно, позтому предпочтение сле- 
дует отдатБ методу. Ч считаго, что в классах, производшлх от MarshalByRefOb ject, 
никогда не следует исполвзоватБ своиства. 

□ При несколвких вБ 130 вах подрнд своиство-метод может возврагцатв разнБ1е 
значенгш, а поле возврагцает одно и то же значение. В классе System . DateTime 
еств неизменнемое своиство Now, которое возврагцает текугцие дату и времн. При 
каждом последугогцем ввгзове своиство возврагцает новое значение. Зто ошибка, 
и в компании Microsoft охотно исправили 6бг зтот класс, превратив Now в метод. 
Другои пример подобнои ошибки — своиство Environment.TickCount. 

□ Своиство-метод может порождатв видимБге побочнБге зффектБг, невозможнБге 
при доступе к полго. Иначе говорн, порндок определенгш значении различнвгх 
своиств типа никак не должен влгштб на поведение типа, однако в деиствителв- 
ности часто бнгвает не так. 

□ Своиству-методу может требоватвсл дополнителБнан памнтн или ссБглка на 
обвект, не нвлнгогцииси частвго состоннгш обвекта, позтому изменение возвра- 
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тцаемого обЂекта никак не сказмваетсл на исходном обвекте; при запросе поли 
всегда возврагцаетсл ссмлка на обвект, которми гарантированно относитсл 
к состомш! io исходного оОЂСкта. Своиство, возврагцакзгцее когано, — источник 
путаницм дли разработчиков, причем об зтом часто забмвагот упомлнутЂ в до- 
кументации. 

И считаго, что разработчики исполЂзугот своиства намного чагце, чем следовало 
бм. Достаточно внимателЂно изучитЂ список различии между своиствами и полл- 
ми, чтобм поннтђ: естЂ оченЂ немного ситуации, в котормх определение своиства 
деиствителЂно полезно, удобно и не запутмвает разработчика. Единственнал при- 
влекателЂнан черта своиств — упрогценнми синтаксис, все осталЂное — недостатки, 
в числе котормх потерн в производителЂности и читабелЂности кода. Если бм и 
участвовал в разработке .NET Framework и компилнторов, н бм вообгце отказалсн от 
своиств, вместо зтого н предоставил бм разработчикам полнуго свободу реализации 
методов GetXxx и SetXxx. Позже создатели компилнторов могли бм предоставитБ 
особми упрогценнми синтаксис вмзова зтих методов, но толбко при условии его 
отличгш от синтаксиса обрагценгш к полнм, чтобм программист четко понимал, что 
вмполннетсн вмзов метода! 


Своиства и отладчик Visual Studio 

Microsoft Visual Studio позволнет указмватБ своиства обвектов в окне просмотра 
отладчика. В резулшате при задании точки останова отладчик будет вмзмватБ ме- 
тод get и показБшатБ возврагцаемое значение. Зто может 6бгтб полезно при поиске 
ошибок, но также может сказатпсн на точности и производителБности приложенгш. 
Например, пустп вбг создали поток FileStream длн фаила, передаваемого по сети, 
и затем добавили своиство FileStream . Length в окно просмотра отладчика. Каждвпг 
раз при переходе к точке останова отладчик ввгзовет метод доступа get, которвпг во 
внутреннеи реализации вбгполнит сетевои запрос к серверу длн полученгш текугцеи 
ДЛИНБ 1 фаила! 

АналогичнБш образом, если метод доступа get производит какои-то побоч- 
нБги зффект, то зтот зффект всегда будет вбгполнптбсл при достижении точки 
останова. Например, если метод доступа get увеличивает счетчик каждвш раз во 
времн вБгзова, то зтот счетчик будет каждвги раз увеличиватБСн на точке останова. 
Из-за зтих потеициалБНБгх проблем Visual Studio позволлет отклгочитб режим 
вБгчислении длл своиств, указаннБгх в окне просмотра отладчика. Длл зтого ввгбе- 
рите команду Tools ► Options, в списке открБгвшегосн окна Options раскроите ветвБ 
Debugging ► General и сбросите флажок Enable Property Evaluation And Other Implicit 
Function Calls (рис. 10.1). Обратите внимание, что даже отклгочив таким образом 
вБгчисленгш длн своиства, все равно можно будет добавитв своиство в окно про- 
смотра отладчика и вручнуго запуститв вБгчисленгш, гцелкнув мбгшбго на значке 
вБгчислении в колонке Value окна просмотра отладчика Visual Studio. 
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Рис. 10.1. Настроики отладчика Visual Studio 


Инициализаторм обвектов и коллекции 

Создание обЂекта с заданием некотормх открмтмх своиств (или полеи) — чрезвм- 
чаино распространеннаи операции. Длн ее упротцешш в C# предусмотрен специ- 
алЂнми синтаксис инициализации обвекта, например: 

Employee е = new Employee() { Name = "Deff'j Age = 45 }; 

B зтом вмражении н создаго обвект Employee, вмзмван его конструктор без па- 
раметров, и затем назначаго открмтому своиству Name значение Deff, а открмтому 
своиству Age — значение 45. Зтот код идентичен следугогцему коду (в зтом нетрудно 
убедитЂСи, просмотрев IL -код обоих фрагментов): 

Employee е = new Employee(); 
e.Name = "Deff"; 
e.Age = 45; 

РеалЂнаи вмгода от синтаксиса инициализатора обвекта состоит в том, что 
он позволлет программироватЂ в контексте вмраженгш, строи функции, которме 
улучшагот читабелЂностЂ кода. Например, можно написатЂ: 

String s = new Employee() { Name = "leff", Age = 45 }.ToString().ToUpper(); 

B одном вмражении н сконструировал обвект Employee, вмзвал его конструктор, 
инициализировал два открмтмх своиства, вмзвал метод ToStning, а затем метод 
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ToUpper. C# также позволнет опуститБ круглме скобки перед открмвагогцеи фигур- 
нои скобкои, если вм хотите вмзватБ конструктор без параметров. Длн следугогцего 
фрагмента генерируетсл программнБш код, идентичнБпг предБвдугцему: 

String s = new Employee { Name = "Deff", Age = 45 }.ToString().ToUpper(); 

Если тип своиства реализует интерфеис IEnumerable или IEnumerable<T>, 
то своиство пвллетсл коллекциеи, а инициализацин коллекции пвлиетсл до- 
полннгогцеи операциеи (а не заменнгогцеи). Например, пуств имеетси следугогцее 
определение класса: 

public sealed class Classroom { 

private List<String> m_students = new List<String>(); 
public List<String> Students { get { return m_students; } } 

public Classroom() {} 

} 

Следугогции код создает обвект Classroom и инициализирует коллекциго Stu- 
dents: 

public static void M() { 

Classroom classroom = new Classroom { 

Students = { "Deff", "Kristin", "Aidan", "Grant" } 

}J 


// Вивести имена 4 студентов, находншихсн в классе 
foreach (var student in classroom.Students) 
Console.WriteLine(student); 

} 


Bo времи компилнции зтого кода компилнтор увидит, что своиство Students 
имееттип List<String> ичто зтоттипреализуетинтерфеис IEnumerable<String>. 
Компшвдтор предполагает, что тип List<String> предоставлнет метод с именем 
Add (потому что болБшинство классов коллекции предоставлиет метод Add длл 
добавленгвд злементов в коллекциго). Затем компилитор сгенерирует код дли bbi- 
зова метода Add коллекции. В резулвтате представленнБш код будет преобразован 
компилитором в следугогцгш: 

public static void М() { 

Classroom classroom = new Classroom(); 
classroom.Students.Add("Deff"); 
classroom.Students.Add("Kristin"); 
classroom.Students.Add("Aidan"); 
classroom.Students.Add("Grant"); 

// Вивести имена 4 студентов, находншихсн в классе 
foreach (var student in classroom.Students) 

Console.WriteLine(student); 

} 
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Если тип своиства реализует интерфеис IEnumerable или IEnumerable<T>, но 
не предлагает метод Add, тогда компилитор не разрешит исполБЗОватБ синтаксис 
инициализации коллекции длл добавленгш злемента в коллекцшо, вместо зтого 
компилитор ввгведет такое сообгцение (ошибка CS0H7: System . Collections . 
Generic . IEnumerable<string> не содержит определенгш длл Add): 

error CS0117: ' System.Collections.Generic . IEnumerable<string> ' does not 

contain a definition for 'Add' 

Некоторвге методБ 1 Add принимагот различннге аргументБт Например, вот метод 
Add класса Dictionary: 

public void Add(TKey кеу л TValue value); 

При инициализации коллекции методу Add можно передатв несколБКО аргумен- 
тов, длл чего исполвзуетсл синтаксис с фигурнкши скобками: 

var table = new Dictionary<Stringj Int32> { 

{ "leffrey"j 1 }, { "Kristin", 2 }, { "Aidan", 3 }, { "Grant", 4 } 

H 

Зто равносилБно следукнцему коду: 

var table = new Dictionary<String, Int32>(); 
table.Add("leffrey", 1); 
table.AddC'Kristin", 2); 
table.Add("Aidan", 3); 
table.Add("Grant", 4); 


Анонимнне типм 

Механизм анонимнБ 1 х типов в C# позволиет автоматически о6бнвитб кортежнБп! 
тип при помогци простого синтаксиса. Кортежнип mun (tuple type)‘ — зто тип, 
которБП! содержит коллекциго своиств, каким-то образом свизаннБ1х друг с дру- 
гом. В первои строке следуклцего программного кода н определиго класс с двумн 
своиствами (Name типа String и Year типа Int32), создаго зкземплнр зтого типа 
и назначаго своиству Name значение leff , а своиству Year — значение 1964. 

// Определение типа, создание сушности и инициализацил своиств 
var ol = new { Name = "leff ", Year = 1964 }; 

// Вивод своиств на консолц 

Console.WriteLine("Name={0}, Year={l}", ol.Name, ol.Year); // Виводит: 

// Name=3eff, Year=1964 

Здесв создаетсн анонимнБш тип, потому что не 6бш определен тип имени после 
слова new, таким образом, компилитор автоматически создает имн типа, но не со- 


1 Термин «tuple» возник как «обобшение» последователБности: single, double, triple, 
quadruple, quintuple, n-tuple. 
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обшдет какое оно (позтому тип и назван анонимнмм). ИсполБЗОвание синтаксиса 
инициализации обвекта обсуждалосв в предмдушем разделе. Итак, н, как разработ- 
чик, не имего поннтин об имени типа на зтапе компилнции и не знаго, с каким типом 
бмла обЂнвлена переменнан ol. Однако проблемм здесЂ нет — н могу исполЂЗОватЂ 
механизм неивнои типизации локалЂнои переменнои, о котором говоритсл в гла- 
ве 9, чтобм компилнтор определил тип по вмраженшо в правои части оператора 
присваиванин (=). 

Итак, посмотрим, что же деиствителБно делает компилнтор. Обратите внимание 
на следугошии код: 

var о = new { propertyl = expressionl, propertyN = expressionN }; 

Когда вм пишете зтот код, компиллтор определлет тип каждого вмраженин, 
создает закрмтме полн зтих типов, дли каждого типа полн создает открмтме свои- 
ства толбко дли чтенин и длн всех зтих вмражении создает конструктор. Код кон- 
структора инициализирует закрмтме поли толбко длн чтенгш путем вмчисленгш 
резулБтиругогцих значении. В дополнение к зтому, компиллтор переопределлет 
методм Equals, GetHashCode и ToStning обвекта и генерирует код внутри всех 
зтих методов. Класс, создаваемми компилнтором, вмгллдит следугогцим образом: 
[CompilerGenerated] 

internal sealed class <>f_AnonymousType0<...>: Object { 

private readonly tl fl; 

public tl pl { get { return fl; } } 


private readonly tn fn; 

public tn pn { get { return fn; } } 

public <>f_AnonymousType0<...>(tl al, ..., tn an) { 

fl = al; ...; fn = an; // Назначает все полл 

} 

public override Boolean Equals(Object value) { 

// Возврашает false, если какие-либо полл не совпадатт; 

// иначе возврашаетсв true 

} 

public override Int32 GetHashCode() { 

// Возврашает хеш-код, сгенерированнши из хеш-кодов полеи 

} 

public override String ToStringO { 

// Возврашает парш "name = value", разделеннше точками 

} 

} 

Компилнтор генерируетметодм Equals и GetHashCode, чтобм зкземплирм ано- 
нимного типа моги размегцагБСн в хеш-таблицах. Неизменнемме своиства, в отличие 
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от своиств длн чтенин и записи, помогагот загцититБ хеш-код обвекта от изменении. 
Изменение хеш-кода обвекта, исполБзуемого в качестве клкзча в хеш-таблице, мо- 
жет помешатБ нахожденшо обвекта. Компилчтор генерирует метод ToStning дли 
упрогценин отладки. В отладчике Visual Studio можно навести указателБ ммши на 
переменнуго, свнзаннуго с зкземплнром анонимного типа, и Visual Studio вмзовет 
метод ToStning и покажет резулБтирукчцуго строку в окне подсказки. Кстати, 
IntelliSense -окно в Visual Studio будет предлагатБ имена своиств в процессе на- 
писании кода в редакторе — оченв полезнан функцин. 

Компшштор поддерживает два дополнителБнвгх варианта синтаксиса обБнвле- 
Н 1 ш своиства внутри анонимного типа, где на основании переменнвгх определнготсн 
имена и типбг своиств: 

String Name = "Grant"; 

DateTime dt = DateTime.Now; 

// Анонимнии тип c двумн своиствами 

// 1. Строковому своиству Name назначено значение Grant 
// 2. Своиству Year типа Int32 Year назначен год из dt 
var о2 = new { Name, dt.Year }; 

B данном примере компилитор определлет, что первое своиство должно на- 
ЗБшатвсл Name. Так как Name — зто ими локалкнои переменнои, то компилитор 
устанавливает значение типа своиства аналогичного типу локалвнои переменнои, 
то естБ Stning. Длл второго своиства компилитор исполвзует ими поли/своиства: 
Yean. Yean — своиство класса DateTime с типом Int32, а следователвно, своиство 
Yean в анонимном типе будет относитбси к типу Int32. Когда компилитор создает 
зкземплнр анонимного типа, он назначает зкземплнру Name своиство с тем же зна- 
чением, что и у локалвнои переменнои Name, так что своиство Name будет свизано 
со строкои Gnant. Компилнтор назначит своиству зкземплнра Yean то же значение, 
что и возврагцаемое значение из dt своиства Yean. 

Компшштор оченв разумно вБшснчет анонимнБггг тип. Если компшштор видит, 
что вбг определили множество анонимнвгх типов с идентичнвгми структурами, 
то он создает одно определение длл анонимного типа и множество зкземплнров 
зтого типа. Под одинаковои структурои л подразумеваго, что анонимнвге типбг 
имегот одинаковБге тип и ими длн каждого своиства и что зти своиства определенвг 
в одинаковом поридке. В коде из приведенного примера тип переменнои ol и тип 
переменнои о2 одинаков, так как в двух строках кода определен анонимнвги тип со 
своиством Name/Stning и Yean/Int32, и Name стоит перед Yean. 

Раз две переменнвге относлтсл к одному типу, открнгваетсл масса полезнвгх воз- 
можностеи — например, проверитв, содержат ли два обвекта одинаковвге значенин, 
и присвоитБ ссБглку на один обвект переменнои другого обвекта: 

// Совпадение типов позволнет осуцествлвтв операции сравненив и присваиванин 
Console.WriteLine("Objects are equal: " + ol . Equals(o2) ); 
ol = 02; // Присваивание 
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Раз зти типм идентичнм, то можно создати массив нвнб1х типов из анонимнБ1х 
типов (о массивах см. главу 16 ): 

// Зто работает, так как все обвектн имен5 один анонимнми тип 
var people = new[] { 

ol, // См. ранее в зтом разделе 
new { Name = "Kristin", Year = 1970 }, 
new { Name = "Aidan", Year = 2003 }, 
new { Name = "Grant", Year = 2008 } 

}; 

// Организацил перебора массива анонимнмх типов 
// (клтчевое слово var облзателвно). 
foreach (var person in people) 

Console.WriteLine("Person={0}, Year={l}", person.Name, person.Year); 

АнонимнБ1е типб1 о6бшно исполБзуготси c технологиеи нзБ1ка интегрированнБ1Х 
запросов (Language Integrated Query, LINQ), когда в резулБтате вБшолненин запро- 
са создаетсл коллекцгш обвектов, относигцихси к одному анонимному типу, после 
чего производитси обработка обвектов в полученнои коллекции. Все зто делаетси 
в одном методе. В следугогцем примере все фаилБ1 из папки с моими документами, 
которБге 6б1ли измененБ 1 в последние семБ днеи: 

String myDocuments = 

Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments); 
var query = 

from pathname in Directory.GetFiles(myDocuments) 
let LastWriteTime = File.GetLastWriteTime(pathname) 
where LastWriteTime > (DateTime.Now - TimeSpan.FromDays(7)) 
orderby LastWriteTime 

select new { Path = pathname, LastWriteTime }; 

foreach (var file in query) 

Console.WriteLine("LastWriteTime={0}, Path={l}", 
file.LastWriteTime, file.Path); 

ЗкземплнрБ1 анонимного типа не должибг вбгходитб за пределБ1 метода. В про- 
тотипе метода не может содержатБсл параметр анонимного типа, так как задатБ 
анонимнБш тип невозможно. По тому же принципу метод не может возврагцатБ 
ссБшку на анонимнБП! тип. Хотн зкземплир анонимного типа может интерпрети- 
роватБСл как Object (все анонимнБге тнпбг нвлнготсл производнБши от Object), 
преобразоватБ переменнуго типа Object обратно к анонимному типу невозможно, 
потому что ими анонимного типа на зтапе компилицгш неизвестно. Длн передачи 
кортежного типа следует исполБЗОватБ тип System.Tuple, о котором речБ идет 
в следугогцем разделе. 

Тип System.Tuple 

В пространстве имен System определено несколБКО обобгценнБгх кортежнБгх типов 
(все они наследуготсл от класса Ob ject), которБге отличаготсн количеством обобгцен- 
Hbix параметров. Приведу наиболее простуго и наиболее сложнуго формБ! записи. 
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// Простаа форма: 

[Serializable] 
public class Tuple<Tl> { 
private Т1 m_Iteml; 

public Tuple(Tl iteml) { m_Iteml = iteml; } 
public Т 1 Iteml { get { return m_Iteml; } } 

} 

// Сложнал форма: 

[Serializable] 

public class Tuple<Tl, T2, ТЗ, T4, T5, T6, T7, TRest> { 
private Т1 m_Iteml; private T2 m_Item2; 
private ТЗ m_Item3; private T4 m_Item4; 
private T5 m_Item5; private T6 m_Item6; 
private T7 m_Item7; private TRestm_Rest; 

public Tuple(Tl itemlj T2 item2j ТЗ item3, 

T4 item4, T5 item5, T6 item6, T7 item7, TRest t) { 

m_Iteml = iteml; m_Item2 = item2; m_Item3 = item3; m_Item4 = item4; 
m_Item5 = item5; m_Item6 = item6; m_Item7 = item7; m_Rest = rest; 

} 


public 

Т1 

Iteml 

{ 

get 

{ 

return 


Iteml; 

} 

} 

public 

T2 

Item2 

{ 

get 

{ 

return 

m_ 

_Item2; 

} 

} 

public 

ТЗ 

Item3 

{ 

get 

{ 

return 

m_ 

_Item3; 

} 

} 

public 

T4 

Item4 

{ 

get 

{ 

return 

m_ 

_Item4; 

} 

} 

public 

Т5 

Item5 

{ 

get 

{ 

return 

m_ 

_Item5; 

} 

} 

public 

Т6 

Item6 

{ 

get 

{ 

return 

m_ 

_Item6; 

} 

} 

public 

Т7 

Item7 

{ 

get 

{ 

return 

m_ 

_Item7; 

} 

} 

public 

TRest Rest 

{ get 

{ return 

m_Rest 

i 

} } 


} 


Как и обЂектм анонимного типа, обкект Tuple создаетсл один раз и остаетсл 
неименнмм (все своиства доступнм толђко длл чтенил). И не привожу соответ- 
ствугогцих примеров, но классм Т u P le также позволигот исполЂЗОватЂ методм 
CompareTo, Equals, GetHashCode и ToString, как и своиство Size. К тому же все 
типм Tuple реализугот интерфеисм IStructuralEquatable, IStructuralComparable 
и IComparable, позтому вм можете сравниватЂ два обвекта типа Tuple друг с дру- 
гом и смотретБ, как их полн сравниваготсл. Длн деталћного изученин зтих методов 
и интерфеисов посмотрите документациго SDK. 

Приведу пример метода, исполБзугогцего тип Tuple длн возврагценин двух частеи 
информации в вБгзБгвагогции метод. 

// Возврацает минимум в Iteml и максимум в Item2 
private static Tuple<Int32, Int32>MinMax(Int32 a, Int32 b) { 
return new Tuple<Int32, Int32>(Math.Min(a, b), Math.Max(a, b)); 

} 

// Пример вмзова метода и исполизованил Tuple 
private static void TupleTypes() { 
varminmax = MinMax(6, 2); 


продолжение & 
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Console.WriteLine("Min={0}, Мах={1}", 

minmax.Iteml, minmax.Item2); // Min=2, Max=6 

} 

Конечно, оченв важно, чтобм и производителБ, и потребителБ типа Т uple имели 
четкое представление о том, что будет возврандатБСи в своиствах Item#. С аноним- 
нбши типами своиства получагот деиствителБНБ1е имена на основе программного 
кода, определнгогцего анонимнвп! тип. С типами Т uple своиства получагот их имена 
автоматически, и bbi не можете их изменитв. К несчастБГО, зти имена не имегот на- 
стонгцего значенин и смнгсла, а зависнт от производителн и потребители. Зто также 
ухудшает читабелвноств кода и удобство его сопровожденин, так что bbi должнб1 
добавлитБ комментарии к коду, что6б1 о6биснитб, что именно производителБ/по- 
требителБ имеет в виду. 

Компилнтор может толбко подразумеватБ обобгценнБ1и тип во времи вБ 130 ва 
обобгценного метода, а не тогда, когда bbi вБгзвшаете конструктор. В силу зтои при- 
чинб1 пространство имен System содержит статическии необобгценнБП! класс Tuple 
с набором статических методов Create, которвге могут определнтв обобгценнБге 
типБ1 по аргументам. Зтот класс деиствует как фабрика по производству обвектов 
типа Tuple и сугцествует просто длл упрогценгш вашего кода. Вот переписаннан 
с исполБЗОванием статического класса Tuple версгш метода MinMax: 

// Возврацает минимум в Iteml и максимум в Item2 

private static Tuple<Int32, Int32>MinMax(Int32 a, Int32 b) { 

return Tuple.Create(Math.Min(a, b), Math.Max(a, b)); // Упрошеннии 

// синтаксис 

} 

Что6б 1 создатв тип Tuple с более, чем восбмбго злементами, передаите другои 
обвект Tuple в параметре Rest: 

var t = Tuple.Create(0, 1, 2, 3, 4, 5, 6, Tuple.Create(7, 8)); 

Console.WriteLine("{0}, {1}, {2}, {3}, {4}, {5}, {6}, {7}, {8}", 
t.Iteml, t.Item2, t.Item3, t.Item4, t.ItemS, t.Item6, t.Item7, 
t.Rest.Iteml.Iteml, t.Rest.Iteml.Item2); 


ПРИМЕЧАНИЕ 

Кроме анонимнмхи кортежнмхтипов, стоитприсмотретБса кклассу System.Dynamic. 
ExpandoObject (определенному в сборке System.Core.dll assembly). При исполБзова- 
нии зтого класса с динамическим типом C# (о котором говоритсл в главе 5) полвлчетсл 
другои способ группировки наборов своиств (пар клкзч-значение) вместе. Получен- 
Hbiiži в резулБтате тип не обладает безопасностБкз типов на стадии компиллции, зато 
синтаксис внгллдит отлично (хотл вм лишаетесБ поддержки IntelliSense), а обвектм 
ExpandoObject могут передаватБСл между C# и такими динамическими лзмками, как 
Python. Пример кода с исполБЗОванием обвекта ExpandoObject: 

dynamic е = new System.Dynamic . ExpandoObject (); 
е.х = 6; // Добавление своиства 'х' типа Int32 

// со значением 6 
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е.у = "Deff"; // Добавление своиства 'у' строкового типа 
// со значением "Jeff" 

e.z = null; // Добавление своиста 'z' обиекта 
// со значением null 

// Просмотр всех своиств и других значении 
foreach (var v in (IDictionary<String, Object>)e) 
Console.WriteLine("Key={0}, V={1}", v.Key, v.Value); 

// Удаление своиства 'х' и его значенин 
var d = (IDictionary<Stringj Object>)e; 
d.Remove("x"); 


Своиства c параметрами 

У своиств, рассмотреннмх в предмдушем разделе, методм доступа get не прини- 
мали параметрм. Позтому и назмваго их свопствами без параметров (parameterless 
properties). Они прогце, так как их исполБЗОвание напоминает обрагцение к iio.tio. 
Помимо таких <<полеобразнмх» своиств, нзмки программировангш поддерживагот 
то, что и назмваго свопствами с параметрами (parameterful properties). У таких 
своиств методм доступа get получагот один или песко. њко параметров. Разнме 
нзмки поддерживагот своиства с параметрами по-разному. Кроме того, в разнмх 
нзмках своиства с параметрами назмвагот по-разному: в C# — индексаторм, в Visual 
Basic — свопства no умолчанит. Здесг> и остановлгосБ на поддержке индексаторов 
в C# на основе своиств с параметрами. 

В C# синтаксис своиств с параметрами (индексаторов) напоминает синтаксис 
массивов. Иначе говори, индексатор можно представитБ как средство, позволнго- 
mee разработчику на C# перегружатБ оператор [ ]. В следукнцем примере класс 
BitArray позволлет индексироватБ набор битов, поддерживаемми зкземплнром 
типа, с исполвзованием синтаксиса массива: 

using System; 

public sealed class BitArray { 

// Закритми баитовми массив, хранпции бити 
private Byte[] m_byteArray; 
private Int32 m_numBits; 

// Конструктор, виделнккции памлтв длл баитового массива 
// и устанавливакнции все битм в 0 
public BitArray(Int32 numBits) { 

// Начинаем с проверки аргументов 
if (numBits <= 0 ) 

throw new ArgumentOutOfRangeException("numBits must be > 0"); 

// Сохранитв число битов 
m_numBits = numBits; 

// Вмделитв баитт длн массива битов 

продолжение & 



280 Глава 10. Своиства 


m_byteAmay = new Byte[(numBits + 7) / 8]; 

} 

// Индексатор (своиство c параметрами) 
public Boolean this[Int32 bitPos] { 

// Метод доступа get индексатора 
get { 

// Сначала нужно проверитч аргумен™ 
if ((bitPos < 0) || (bitPos >= m_numBits)) 

throw new ArgumentOutOfRangeException("bitPos"); 

// Вернутч состолние индексируемого бита 

return (m_byteArray[bitPos / 8] & (1 << (bitPos % 8))) != 0; 

} 

II Метод доступа set индексатора 
set { 

if ((bitPos < 0) || (bitPos >= m_numBits)) 
throw new ArgumentOutOfRangeException( 

"bitPos", bitPos.ToString()); 
if (value) { 

// Установитв индексируемми бит 
m_byteArray[bitPos / 8] = (Byte) 

(m_byteArray[bitPos / 8] | (1 << (bitPos % 8))); 

} else { 

// Сброситч индексируемии бит 
m_byteArray[bitPos / 8] = (Byte) 

(m_byteArray[bitPos / 8] & ~(1 << (bitPos % 8))); 

} 

} 

} 

} 


Исполћзоватћ индексатор типа BitArray неверонтно просто: 

// ВуделитБ массив BitArray, которми может хранитч 14 бит 
BitArray ba = new BitArray (14); 

// УстановитБ все neTHbie битћ1 вћвовом метода доступа set 
for (Int32 х = 0; х < 14; х++) { 
ba[x] = (х % 2 == 0); 

} 

// BbiBecTH состолние всех битов вмзовом метода доступа get 
for (Int32 х = 0; х < 14; х++) { 

Console.WriteLine("Bit " + х + " is " + (ba[x] ? "On" : "Off")); 

} 

B типе BitArray индексатор принимает один параметр bitPos типа Int32. 
У каждого индексатора должен 6 bitb хоти 6б1 один параметр, но параметров может 
6б1тб и болБше. Тип параметров (как и тип возврагцаемого значенин) может 6 bitb 
лјо6б1м. Пример индексатора с несколБкими параметрами можно наити в классе 

System . Drawing . Imaging . ColorMatrix из сборки System.Drawing.dll. 
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Индексаторм доволбно часто создаготсл длн поиска значении в ассоциативном 
массиве. Тип System.Collections.Genenic.Dictionary предлагает индексатор, 
которми принимает клгоч и возврагцает свнзанное с клгочом значение. В отличие 
от своиств без параметров, тип может поддерживатБ множество перегруженнБ 1 х 
индексаторов при условии, что их сигнатурБ1 различнБт 

Подобно методу доступа set своиства без параметров, метод доступа set индек- 
сатора содержит скрвпвш параметр (в C# его назвшагот value), которвш указвшает 
новое значение «индексируемого злемента». 

CLR не различает своиства без параметров и с параметрами. Дли средБ 1 лгобое 
CBoiicTBO — зто всего лишб пара методов, определеннБ 1 х внутри типа. Как уже отме- 
чалосв, в различнБ1х нзБжах синтаксис создангш и исполБЗОванин своиств с параме- 
трами разнБш. ИсполБЗОвание длл индексатора в C# конструкции this [... ] — всего 
лишб решение, приннтое создателими нзБгка, означагогцее, что в C# индексаторвг 
могут определнтБСн толбко длн зкземплнров обвектов. В C# нет синтаксиса, позво- 
лнгогцего разработчику определнтв статистггческое своиство-индексатор напрнмуго, 
хотл на самом деле CLR поддерживает статические своиства с параметрами. 

ПосколБку CLR обрабатБгвает своиства с параметрами и без них одинаково, 
компшштор генерирует в итоговои управлиемои сборке два или три злемента из 
следугогцего списка: 

□ метод get своиства с параметрами генерируетсл толбко в том случае, если 
у своиства определен метод доступа get; 

□ метод set своиства с параметрами генерируетсл толбко в том случае, если 
у своиства определен метод доступа set; 

□ определение своиства в метаданнвгх управлнемого модули генерируетсл всегда; 
в метаданнБгх нет отделБнои таблицБг длн храненгш определении своиств с па- 
раметрами: ведв длн CLR своиства с параметрами — просто своиства. 

Компилнцгш показанного ранее индексатора типа BitArray происходит так, как 
если 6бг он исходно 6бгл написан следугогцим образом: 

public sealed class BitArray { 

// Метод доступа get индексатора 

public Boolean get_Item(Int32 bitPos) {/*...*/} 

// Метод доступа set индексатора 

public void set_Item(Int32 bitPos, Boolean value) {/*...*/} 

} 

Компшштор автоматически генерирует имена зтих методов, добавлии к имени 
индексатора префикс get_ или set_. Посколвку синтаксис индексаторов в C# не 
позволнет разработчику задаватв имн индексатора, создателлм компиллтора C# 
пришлосБ самостолтелБно внгбратБ имн дли методов доступа, и они ввгбрали Item. 
Позтому имена созданнигх компиллтором методов — get_Item и set_Item. 
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Если в справочнои документации .NET Framework указано, что тип поддержи- 
вает своиство Item, значит, даннми тип поддерживает индексатор. Так, тип System . 
Collections .Generic . List предлагает открмтое зкземпллрное своиство Item, 
которое нвлнетсл индексатором обвекта List. 

Программирул на С#, вм никогда не увидите ими Item, позтому вмбор его 
компилитором обмчно не должен вмзмватБ беспокоиства. Однако если Bbi раз- 
рабатБ1ваете индексатор длл типа, которвпг будет исполБЗОватБСн в программах, 
написаннБ1х на других нзБшах, возможно, придетсл изменитв имена методов до- 
ступа индексатора (get и set). C# позволнет переименоватв зти методБ1, применив 
к индексатору полБЗОвателБСКии атрибут System . Runtime . CompilerServices . 
IndexerNameAttribute. Пример: 

using System; 

using System.Runtime.CompilerServices; 

public sealed class BitArray { 

[IndexerName("Bit")] 

public Boolean this[Int32 bitPos] { 

// ЗдесБ определен по краинеи мере один метод доступа 

} 

} 

Теперк компилитор сгенерирует вместо методов get_Item и set_Item методБ1 
get_Bit и set_Bit. Во времч компилнции компилнтор C# обнаруживает атрибут 
IndexerName, которвиг сообгцает ему, какие имена следует присвоитв методам 
и метаданнБш своиств; сам по себе атрибут не вклкзчаетсл в метаданнвш сборки 1 . 

Приведу фрагмент кода на извше Visual Basic, демонстриругогции обрагцение 
к индексатору, написанному на С#: 

' СоздатБ зкземпллр типа BitArray 
Dim ba as New BitArray(10) 

' B Visual Basic индекс злемента массива задаетсл в круглмх скобках (), 

' а не в квадратнмх []. 

Console.WriteLine(ba(2)) " Вуводит True или False 

' Visual Basic также позволвет обравдатвсл к индексатору по имени 
Console . WriteLine(ba . Bit(2) ) ' Виводит то же, что предидутал строка 

В C# в одном типе можно определлтв несколБКО индексаторов при условии, 
что они получагот ра.з m>i е наборБ1 параметров. В других лзБ1ках программирова- 
нгш атрибут IndexerName позволиет задатв несколБКО индексаторов с одинаковои 
сигнатурои, посколвку их имена могут отличатнсн. Однако C# не допускает зтого, 
так как принитБш в C# синтаксис не позволнет ссБглатвсн на индексатор по имени, 


1 По 3Toft причине класс IndexerNameAttribute не входит в описаннне в ЕСМА стандартн 
CLI и лзнка С#. 
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азначит, компилнтор не будет знатћ, накакои индексатор ссБшаготсн. При iioiii.itkc 
компилиции следугошего исходного текста на C# компилитор вБвдает сообгцение 
об ошибке (ошибка CSOlll: в классе SomeType уже определен член this с таким 
же типом параметра): 

еггог CS0111: Class 'SomeType' already defines a member called 'this' with the same 

parameter types 

Фрагмент кода, приводшции к ввгдаче зтого сообгценгш: 
using System; 

using System.Runtime.CompilerServices; 

public sealed class SomeType { 

// Определпем метод доступа get_Item 
public Int32 this[Boolean b] { 
get { return 0; } 

} 

// Определпем метод доступа get_Deff 
[IndexerName("Deff")] 
public String this[Boolean b] { 
get { return null; } 

} 

} 

Как видите, C# рассматривает индексаторвг как механизм перегрузки операто- 
ра [ ], и зтот оператор не позволлет различатв своиства с одинаковвгми наборами 
параметров и разнвгми именами методов доступа. 

Кстати, в качестве примера типа с измененнвгм именем индексатора можно при- 
вести тип System. String, в котором индексатор String именуетсл Chars, а не Item. 
Зто своггство позволлет получатв отделБНБге символбг из строки. Ббгло решено, что 
длл нзбгков программированин, не исполБзугогцих синтаксис с оператором [] ДЛЛ 
вБгзова зтого своиства, ими Chars будет более информативно. 

Обнаружив попвгтку чтенгш или записи индексатора, компшштор C# генерирует 
вбгзов соответствугогцего метода доступа. Некоторвге лзбгки программировангш 
могут не поддерживатБ своиства с параметрами. Чтобвг получитв доступ к своиству 
с параметрами из программвг на таком нзвгке, нужно нвно ввгзватв желаемБги метод 
доступа. CLR не различает своиства с параметрами и без параметров, позтому длн 
поггска свнзи между своиством с параметрами и его методами доступа исполБзуетсн 
все тот же класс System . Reflection . PropertyInf о. 


Bbi6op главного своиства с параметрами 

При анализе ограничении, которвге C# налагает на индексаторвг, возникает два 
вопроса: 
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□ Что если лзмк, на котором написан тип, позволнет разработчику определитБ 

несколБКО своиств с параметрами? 

□ Как исполБЗОватБ зтот тип в программе на С#? 

Ответ: в зтом типе надо вБ 1 братв один из методов среди своиств с параметра- 
ми и сделатв его своиством по умолчаншо, применив к самому классу зкземплир 
System . Reflection . DefaultMemberAttnibute. Кстати, DefaultMemberAttribute 
можно применнтБ к классам, структурам или интерфеисам. В C# при компилнции 
типа, определигогцего своиства с параметрами, компилитор автоматически при- 
меннет к определигогцему типу зкземплнр атрибута Def aultMember и учитвшает 
его при исполБЗОвании атрибута IndexerName. Конструктор зтого атрибута задает 
ими, которое будет назначено своиству с параметрами, вБ1бранному как своиство 
по умолчаниго длн зтого типа. 

Итак, в C# при определении типа, у которого еств своиство с параметрами, но 
нет атрибута IndexerName, атрибут Def aultMember, задагогции определигогции тип, 
будет указвшатБ ими Item. Если применитБ к своиству с параметрами атрибут 
IndexerName, то атрибут DefaultMember определнгогцего типа будет указвшатв на 
строку, заданнуго атрибутом IndexerName. Помните: C# не будет компилироватБ 
код, содержагции разноименнБге своиства с параметрами. 

В программах на нзвгке, поддерживагогцем несколкко своиств с параметрами, 
нужно ввгбратБ один метод своиства и пометитв его атрибутом Def aultMember. Зто 
будет единственное своиство с параметрами, доступное программам на С#. 


ПроизводителвностБ при внзове 
методов доступа 

В случае проствгх методов доступа get и set JIT -компилнтор подставлпет (inlines) 
код метода доступа внутрв кода вмзмваемого метода, позтому характерного сниже- 
нгш производителБности работБг программБг, пронвлнгогцегосн при исполвзовании 
своиств вместо полеи, не наблгодаетсл. Подстановка подразумевает компилнциго 
кода метода (или, в данном случае, метода доступа) непосредственно вместе с ко- 
дом ББгзБшагогцего метода. Зто избавлиет от дополнителвнои нагрузки, свнзаннои 
с вБгзовом во времп ввшолненгш, но за счет увеличенгш обвема кода откомпилиро- 
ванного метода. Посколвку методкг доступа своиств обвгчно содержат мало кода, 
их подстановка может приводитв к сокрагцениго обгцего обвема машинного кода, 
а значит, к повБшгениго скорости вБшолненгш. 

ЗаметБте, что при отладке ЈГГ-компшштор не подставлиет методвг своиств, по- 
тому что подставленнБш код сложнее отлаживатБ. Зто означает, что зффективностБ 
доступа к своиству в готовои версии программвг вБшге, чем в отладочнои. Что же 
касаетсп полеи, то скороств доступа к ним одинакова в обеих версгшх. 
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ДоступностБ методов доступа своиств 

Иногда при проектировании типа требустсм назначитБ методам доступа get и set 
разнБШ уровенБ доступа. Чагце всего применнгот OTKpbiTbiii метод доступа get и за- 
KpbiTbiii метод доступа set: 

public class SomeType { 
private String m_name; 
public String Name { 
get { return m_name; } 
protected set {m_name = value; } 

} 

} 

Как видно из кода, своиство Name обтив.тепо как public, а зто означает, что ме- 
тод доступа get будет открБ 1 ТБ 1 м и доступнБш дли вБ130ва из лгобого кода. Однако 
следует учестБ, что метод доступа set обтзпгтеп как protected, то естБ он доступен 
дли вБ130ва толбко из кода SomeType или кода класса, производного от SomeType. 

При определении длл своиства методов доступа с различнБши уровннми доступа 
синтаксис C# требует, что 6 б 1 само своиство 6 бшо обБнвлено с наименее строгим 
уровнем доступа, а более жесткое ограничение 6 бшо наложено толбко на один из 
методов доступа. В зтом примере своиство нвлиетсл открБ1ТБ1м, а метод доступа 
set — загцшценнБш (более ограниченнБш по сравнениго с public). 


Обоб|деннме методм доступа своиств 

ПосколБку своиства фактически представлигот co6oii методБ 1 , а C# и CLR поддер- 
живагот параметризациго методов, некоторБге разработчики пБ1таготси определитБ 
своиства с собственнвши параметрами-типами (вместо исполБЗОвангш таких пара- 
метров из внешнего типа). Однако C# не позволлет зтого делатв. Главнаи причина 
в том, что обобгценин своиств лишенБ1 смБгсла с концептуалБнои точки зренгш. 
Предполагаетсн, что своиство представлнет характеристику обвекта, которуго мож- 
но прочитатБ или задатБ. Введение обобгценного параметра типа означало 6bi, что 
поведение операции чтенгш/записи может меннтБСн, но на концептуалБном уровне 
от своиства не ожидаетсн никакого поведенгш. Длн задангш какого-либо поведенгш 
обвекта (обобгценного гши нет) следует создатБ метод, а не своиство. 
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В зтои главе рассматриваетсл последннн разновидностБ членов, которме можно 
определитБ в типе, — собмтин. Тип, в котором определено собмтие (или зкземплн- 
рм зтого типа), может уведомлитБ другие обвектм о некотормх особмх ситуациих, 
которме могут случитБСи. Например, если в классе Button (кнопка) определитБ 
со6р>п ис Click (гцелчок), то в приложение можно исполћзоватБ обЂектБц которБШ 
будут получатћ уведомление о гцелчке обЂекта Button, а получив такое уведомле- 
ние — исполннтђ некоторме деиствгш. Собмтин — зто членм типа, обеспечивакзгцие 
такого рода взаимодеиствие. А именно определенгш собмтин в типе означает, что 
тип поддерживает следугогцие возможности: 

□ регистрацгш своеи заинтересованности в собмтии; 

□ отмена регистрации своеи заинтересованности в собмтии; 

□ оповегцение зарегистрированнмх методов о произошедшем собмтии. 

Типм могут предоставлитЂ зту функционалЂностЂ при определении собмтии, 
так как они поддерживагот список зарегистрированнмх методов. Когда собмтие 
происходит, тип уведомлнет об зтом все зарегистрированнме методм. 

Моделв собмтии CLR основана на делегатах (delegate). Делегатм обеспечива- 
гот реализациго механизма обратного вмзова, безопаснуго по отношениго к типам. 
Методм обратного вмзова (callback methods) позволнгот обвекту получатв уведом- 
ленгш, на которме он подписалси. В зтои главе мм будем постоннно полвзоватЂСи 
делегатами, но их деталЂнми разбор отложим до главм 17. 

Чтобм помочђ вам в полнои мере разобратвсн в работе собмтии в CLR, и нач- 
ну с примера ситуации, в которои могут пригодитЂСн собмтгш. Допустим, мм 
проектируем почтовое приложение. Получив сообгцение по злектроннои почте, 
полЂЗОвателЂ может захотетЂ переслатЂ его на факс или пеиджер. Допустим, вм 
начали проектирование приложенгш с разработки типа MailManagen, получагогце- 
го входшцие сообгценгш. Тип MailManagen будет поддерживатв собмтие NewMail. 
Другие тггпм (например, Fax или Pagen) могут регистрироватЂСи длл полученгш 
уведомлении об зтом собмтии. Когда тип MailManagen получит новое сообгцение, 
он инициирует собмтие, в резулвтате чего сообгцение будет получено всеми заре- 
гистрированнмми обЂектами. Далее каждми обвект обрабатмвает сообгцение так, 
как считает нужнмм. 

ПустЂ во времи инициализации приложенгш создаетси толђко один зкземплир 
MailManagen и лгобое число обвектов Fax и Pagen. На рис. 11.1 показано, как ини- 
циализируетси приложение и что происходит при получении сообгценгш. 
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Рис. 11.1. Архитектура приложенип, в котором исполвзук)тсл собмтил 


При инициализации приложенин создаетсл зкземплир обнекта MailManagen, 
поддерживагошего собмтие NewMail. Во времл создании обвектм Fax и Pager ре- 
гистрируготсп в качестве получателеи уведомлении о собмтии NewMail (приход 
нового сообшенип) обвекта MailManagen, в резулпгате MailManagen «знает», что 
зти обвектм следует уведомитБ о понвлении нового сообгценин. Если в далБнеишем 
MailManagen получит новое сообгцение, зто приведет к вмзову собмтин NewMail, 
позволнгогцего всем зарегистрировавшимсн обвектам вмполнитб требуемуго об- 
работку нового сообгценгш. 


Разработка типа, 
поддерживак)1дего собитие 

Дли создангш типа, поддерживагогцего одно или более собмтии, разработчик должен 
вмполнитб рид деиствии. Все зти деиствгш будут описанм ниже. Наше приложение 
MailManagen (его можно загрузитБ в разделе Books саита http://wintellect.com) со- 
держит весБ необходимћш код типов MailManager, Fax и Pagen. Как вбг заметите, 
типб! Fax и Pagen практически идентичнм. 
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Зтап 1. Определение типа длл храненил 
всеи дополнителБнои информации, 
передаваемои получателлм 
уведомленив о собмтии 

При возникновении собмтил обвект, в котором оно возникло, должен передатБ до- 
полнителБнуго информацшо обБектам-получателим уведомлешш о co6bithh. Длн 
предоставленин получателим зту информацшо нужно инкапсулироватв в собствен- 
нбш класс, содержашии набор закрБгтх полеи и набор открБ1ТБ1х неизменнемБ1х 
(толбко длл чтентш) своиств. В соответствии с соглашением, классвр содержагцие 
информацшо о собвттах, передаваемук) обработчику собвгтил, должнб1 наследоватБ 
от типа System. EventArgs, а имн типа должно заканчиватБСи словом EventArgs. 
В зтом примере у типа NewMailEventArgs еств поли, идентифициругогцие отправи- 
тели сообшешш (m_from), его получатели (m_to) и тему (m_subject). 

// Зтап 1. Определение типа длн храненин информацииЈ 
// которан передаетсл получателнм уведомленин о собмтии 
internal class NewMailEventArgs : EventArgs { 

private readonly String m_from, m_to, m_subject; 

public NewMailEventArgs(String from, String to, String subject) { 
m_from = from; m_to = to; m_subject = subject; 

} 

public String From { get { return m_from; } } 

public String To { get { return m_to; } } 

public String Subject { get { return m_subject; } } 

} 


ПРИМЕЧАНИЕ 

Тип ЕуетАгдзопределзетсз в библиотеке классов .NET FramevvorkClass Library (FCL) 
и вшгллдит примерно следук)ш,им образом: 

[ComVisible(true), Serializable] 
public class EventArgs { 

public static readonly EventArgs Empty = new EventArgs(); 
public EventArgs() { } 

} 

Как видите, в зтом классе нет ничего особенного. Он просто служит базовмм типом, 
от которого можно порождатБ другиетипм. С 6олбшинством собмтии не передаетсл 
дополнителБнои информации. Например, в случае уведомленил обЂектом Button 
о шелчке на кнопке, само обрашение к методу обратного внзова — и естЂ всл нуж- 
наз информациз. Определлз собБ 1 тие, не передакзшее дополнителЂНЂ 1 е даннБ 1 е, 
можно не создаватЂ новми обвект Event-Args, достаточно просто восполЂЗОватЂСл 
своиством EventArgs.Empty. 
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Зтап 2. Определение члена-собмтил 

В C# собмтие обЂнвлиетсл с клгочевмм словом event. Каждому члену-собмтиго 
назначаготсн областЂ деиствил (практически всегда он открмтми, позтому доступен 
из лгобого кода), тип делегата, указмвагогции на прототип вмзмваемого метода (или 
методов), и ими (лгобои допустимми идентификатор). Вот как вмгллдит член- 
собмтие нашего класса NewMail: 
internal class MailManager { 

// Зтап 2. Определение члена-собитил 

public event EventHandler<NewMailEventArgs> NewMail; 


} 

Здесв NewMail — имн собмтин, a типом собмтгш ивлнетси EventHandler <New- 
MailEventArgs>. Зто означает, что получатели уведомлешш о собмтии должнм 
предоставлитв метод обратного вмзова, прототип которого соответствует типу- 
делегату EventHandler<NewMailEventArgs>. Так как обобшеннми делегат System. 
EventHandler определен следугошим образом: 

public delegate void EventHandler<TEventArgs> 

(Object sender, TEventArgs e) where TEventArgs: EventArgs; 

Позтому прототип метода должен вмглидетв так: 

void MethodName(Object sender, NewMailEventArgs e); 


ПРИМЕЧАНИЕ 

Многих удивлпет, почему механизм собмтии требует, чтобм параметр sender имел 
тип Object. Вообиде-то, посколвку MailManager — единственнми тип, реализукзидии 
co6biTHs с обвектом NevvMailEventArgs, 6bmo бм разумнее исполизоваљ следукош,ии 
прототип метода обратного вмзова: 

void MethodName(MailManager sender, NewMailEventArgs e); 

Причинои того, что параметр sender имеет тип Object, нвлнетсн наследование. 
Что произоидет, если MailManager задеиствоваш в качестве базового класса длн 
созданич класса SmtpMailManager? В методе обратного вмзова придетсч в про- 
тотипе задаш параметр sender как SmtpMailManager, а не MailManager, но зтого 
делатв нелизл, так как тип SmtpMailManager просто наследует собмтие NevvMail. 
Позтому код, ожида 1 оидии от SmtpMailManager информацикз о собмтии, все равно 
будет вмнужден приводити аргумент sender к типу SmtpMailManager. Иначе говорн, 
приведение все равно необходимо, позтому параметр sender с таким же успехом 
можно обЂчвиљ с типом Object. 

Еиде одна причина длч обЂлвленил sender с типом Object — гибкостЂ, посколвку 
делегат может применлтвсл несколвкими типами, которме поддержива 10 т собмтие, 
передакзидее обЂект NevvMailEventArgs. В частности, класс PopMailManager мог бм 
ncnoab30BaTb делегат, даже если бм не наследовал от класса MailManager. 
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И еше одно: механизм соби 1 тии требует, чтоби в имени делегата и методе обратного 
вмзова параметр, производнв 1 и от EventArgs, назв 1 валсл «е». Такое требование уста- 
навливаетси по единственнои причине: длл обеспеченил единообразил, облегчаклде- 
го и упрош,а 1 ош,его изучение и реализацикз собмтии разработчиками. Инструментм 
созданил кода (например, такои как Microsoft Visual Studio) также «знак>т», что нужно 
Bbi3biBaTb параметр е. 

И последнее: механизм соби 1 тии требует, чтоби все обработчики возвраш,али void. 
Зто облзателвно, потому что при возникновении собитил могут BbinoAH^Tbcn не- 
сколико методов обратного вмзова и невозможно получиљу них все возвраидаемое 
значение. Тип void просто запреидает методам возвраидати какое 6bi то ни 6bmo 
значение. К сожаленикз, в библиотеке FCL ести обработчики собнтии, в частности 
ResolveEventHandler, в которих Microsoft не следует собственнв 1 м правилам и воз- 
враидает обиект типа Assembly. 


Зтап 3. Определение метода, ответственного 
за уведомление зарегистрированнмх 
обвектов о собмтии 

В соответствшд с соглашением в классе должен бљт> виртуалвнми загцшценнми 
метод, вмзмваемми из кода класса и его потомков при возникновении собмтил. 
Зтот метод принимает один параметр, обвект MailMsgEventArgs, содержагции до- 
полнителБнме сведенин о собмтии. Реализацин по умолчаншо зтого метода просто 
провернет, ec ru ли обвектм, зарегистрировавшиесл длл полученгш уведомленгш о 
собмтии, и при положителБном резулБтате проверки сообгцает зарегистрированнБш 
методам о возникновении собиггии. Вот как вбггллдит зтот метод в нашем классе 
MailManager: 

internal class MailManager { 

// Зтап 3. Определение метода, ответственного за уведомление 
// зарегистрированнмх обиектов о собмтии 

// Если зтот класс изолированнми, нужно сделатв метод закрмтмм 
// или невиртуалБнмм 

protected virtual void OnNewMail(NewMailEventArgs e) { 

// СохранитБ сшлку на делегата во временнои переменнои 
// длл обеспеченил безопасности потоков 

EventHandler<NewMailEventArgs> temp = Volatile.Read (ref NewMail); 

// Если ecTb o6beKTbi, зарегистрированнме длл получении 
// уведомленил о собмтии, уведомллем их 
if (temp != null) temp(this, e); 

} 

} 
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Уведомление о собмтии, безопасное в отношении потоков 

В первом вмпуске .NET Framework рекомендовалосв уведомлнтБ о собмтилх сле- 
дуговдим образом: 

// Версиа 1 

protected virtual void OnNewMail(NewMailEventArgs e) { 
if (NewMail != null) NewMail(this, e); 

} 

Однаков методе OnNewMail кроетсиоднапотенциалБнан проблема. Программ- 
нми поток видит, что значение NewMail не равно null, однако перед вмзовом NewMail 
другои поток может удалитБ делегата из цепочки, присвоив NewMail значение null. 
В резулБтате будет вбџвдно исклнзчение NullRefenenceException. Длн предотвра- 
вденил состоннгш гонки многие разработчики пишут следуговдии код: 

// Версил 2 

protected void OnNewMail(NewMailEventArgs е) { 

EventHandler<NewMailEventArgs> temp = NewMail; 
if (temp != null) temp(this, e); 

} 

Идел заклгочаетсл в том, что ссвшка на NewMail копируетсл во временнуго 
переменнуго temp, которал ссБшаетсл на цепочку делегатов в момент назначе- 
нил. Зтот метод сравнивает temp с null и вБгзвшает temp, позтому уже не имеет 
значенгш, поменил ли другои поток NewMail после назначенгш temp. Вспомните, 
что делегатБг неизмениемБц позтому теоретически зтот способ работает. Однако 
многие разработчики не осознагот, что компиллтор может оптимизироватБ зтот 
программнБпг код, удалив переменнуго temp. В зтом случае обе представленнвге 
версии кода окажутсл идентичнвши, в резулвтате опнтБ-таки возможно исклгочение 
NullRefenenceException. 

Дли реалБного решенгш зтои проблемнг необходимо переписатБ OnNewMail так: 
// версил з 

protected void OnNewMail(NewMailEventArgs е) { 

EventHandler<NewMailEventArgs> temp = Thread.VolatileRead(ref NewMail); 
if (temp != null) temp(this, e); 

} 

Вбгзов VolatileRead заставллет считвгватБ NewMail в точке ввгзова и именно 
в зтот момент копироватБ ссбглку в переменнуго temp. Затем вбгзов temp осувдест- 
влиетсл лишб в том случае, если переменнан не равна null. За дополнителвнои 
информациеи о методе Volatile . Read обравдаитесн к главе 28. 

И хоти последннн версин зтого программного кода нвлнетсл наилучшеи и тех- 
нически корректнои, вбг также можете исполБЗОватБ версиго 2 с Ј1Т-компилнтором, 
не опасансБ за последствин, так как он не будет оптимизироватв программнБги код. 
Все JIT -компшшторБг Microsoft соблгодагот принцип отказа от лишних операции 
чтенгш из кучи, а следователБно, кзширование ссбглки в локалвнои переменнои 
гарантирует, что обравдение по сснглке будет производитБСл всего один раз. Такое 
поведение официалБно не документировано и теоретически может изменитБСи, 
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позтому лучше все же исполБЗОватБ последнкпо версиго представленного про- 
граммного кода. На практике Microsoft никогда не станет вводитб в Ј1Т-компилнтор 
измененин, которБШ нарушат работу слишком многих приложении 1 . Кроме того, со- 
бвттил в основном исполБзуготсн в однопоточнб1х сценаринх (приложенин Windows 
Presentation Foundation и Windows Store), так что безопасностБ потоков вообше 
не создает oco6bix проблем. 

Длн удобства можно определитв метод расширенил (см. главу 8), инкапсули- 
ругогции логику, безопаснуго в отношении потоков. Определите расширеннвш метод 
следуклцим образом: 

public static class EventArgExtensions { 

public static void Raise<TEventAngs>(this TEventAngs e, 

Object sender, ref EventHandler<TEventArgs> eventDelegate) { 

// Копирование ссбшки на поле делегата во временное поле 
// длв безопасности в отношении потоков 

EventHandler<TEventArgs> temp = Volatile.Read(ref eventDelegate); 

// Если зарегистрированнми метод заинтересован в собмтии, уведомите его 
if (temp != null) temptsender, e); 

} 

} 

ТеперБ можно переписатБ метод OnNewMail следугогцим образом: 

protected virtual void OnNewMail(NewMailEventArgs e) { 
e.Raise(this, ref m_NewMail); 

} 

Тип, производнБиг от MailManager, может свободно переопределлтв метод 
OnNewMail, что позволнет производному типу контролироватв срабатБшание со- 
6б1тил. Таким образом, производнБш тип может обрабатБ 1 ватБ новбш сообгценгш 
лго6бш способом по собственному усмотрениго. Обвшно производнБ 1 и тип bhi- 
ЗБшает метод OnNewMail базового типа, в резулвтате зарегистрированнБпг обвект 
получает уведомление. Однако производнвш тип может и отказатнсн от пересБшки 
уведомленгш о собвпии. 

Зтап 4. Определение метода, преобразукицего входнук) 
информацик) в желаемое собмтие 

У класса должен 6bitb метод, принимагогции некоторуго входнуго информациго и в от- 
вет генериругогции собвтге. В примере с типом MailManagen метод SimulateNewMail 
вБ13Бшаетси длн оповегценгш о получении нового сообгценгш в MailManagen: 

internal class MailManager { 

// Зтап 4. Определение метода, преобразуклцего входнут 


1 Менл в зтом заверил участник группм разработки JIT -комшшлтора. 
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// информацик) в желаемое собмтие 

public void SimulateNewMail(String from, String to, String subject) { 

// Создатв обвект длл храненил информации, которуи 
// нужно передатц получателлм уведомленин 

NewMailEventArgs е = new NewMailEventArgs(from, to, subject); 

// BbBBaTb BnpTyanbHbin метод, уведомллккции обцект o собмтии 
// Если ни один из производнмх типов не переопределлет зтот метод, 

// обцект уведомит всех зарегистрированнмх получателеи уведомленил 
OnNewMail(e) ; 

} 

} 

Метод SimulateNewMail принимает информацшо о сообшении и создает новми 
обвект NewMailEventArgs, передаваи его конструктору даннме сообгценгш. Затем 
вмзмваетси OnNewMail — собственнми виртуалБнми метод обвекта MailManagen, 
чтобм формалБно уведомитБ обвект MailManager о новом почтовом сообгцении. 
Обмчно зто вмзмвает инициирование собмтин, в резулвгате уведомлшотси все за- 
регистрированнБге обЂектБт (Как уже отмечалосБ, тип, производнћш от MailManager, 
может переопределлтБ зто деиствие.) 


Реализацил собнтии компиллтором 

Теперв, когда bki умеете определитБ классБ 1 с собБтшми, можно поближе позна- 
комитбсн с самим собљггием и узнатБ, как оно работает. В классе MailManager естБ 
строчка кода, определигогцаи сам член-собБ1тие: 
public event EventHandler<NewMailEventArgs> NewMail; 

При компиллции зтои строки компиллтор преврагцает ее в следугогцие три 
конструкции: 

// 1. ЗАКРНТОЕ поле делегата, инициализированное значением null 
private EventHandler<NewMailEventArgs> NewMail = null; 

// 2. OTKPblTblH метод add_Xxx (где Ххх - зто имн собитин) 

// Позволнет обцектам регистрироватцсд длн полученив уведомлении о собитии 
public void add_NewMail(EventHandler<NewMailEventArgs> value) { 

// Цикл и вузов CompareExchange - хитроумнми способ добавленин 
// делегата способом, безопаснмм в отношении потоков 
EventHandler<NewMailEventArgs>prevHandler; 

EventHandler<NewMailEventArgs> newMail = this . NewMail; 
do { 

prevHandler = newMail; 

EventHandler<NewMailEventArgs> newHandler = 

(EventHandler<NewMailEventArgs>) Delegate.Combine(prevHandler, value); 
newMail = Interlocked.CompareExchange<EventHandler<NewMailEventArgs>>( 
ref this.NewMail, newHandler, prevHandler); 


продолжение # 
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} while (newMail != prevHandler); 

} 

// 3. OTKPblTblH метод remove_Xxx (где Ххх - зто имл собитин) 

// Позволдет обвектам отмендтв регистрацик) в качестве 

// получателеи уведомлении о собмтии 

public void remove_NewMail(EventHandler<NewMailEventArgs> value) { 

// Цикл и Bbi 30 B CompareExchange - хитроумнми способ 
// удаленив делегата способом, безопаснмм в отношении потоков 
EventHandler<NewMailEventArgs> prevHandler; 

EventHandler<NewMailEventArgs> newMail = this.NewMail; 
do { 

prevHandler = newMail; 

EventHandler<NewMailEventArgs> newHandler = 

(EventHandler<NewMailEventArgs>) Delegate.Remove(prevHandler л value); 
newMail = Interlocked.CompareExchange<EventHandler<NewMailEventArgs>>( 
ref this.NewMailj newHandlerj prevHandler); 

} while (newMail != prevHandler); 

} 


Перван конструкцин — просто поле соответствугошего типа делегата. Оно со- 
держит ссмлку на заголовок списка делегатов, которме будут уведомлитБСи о воз- 
никновении собмтил. Поле инициализируетсл значением null; зто означает, что 
нет получателеи, зарегистрировавшихси на уведомленгш о собмтии. Когда метод 
регистрирует получателл уведомленгш, в зто поле заноситсл ссмлка на зкземплнр 
делегата EventHandlen<NewMailEventArgs>, которми может, в свого очередБ, ссм- 
латБСн на дополнителБнме делегатм EventHandler<NewMailEventArgs>. Когда полу- 
чателБ регистрируетсн длн полученин уведомлешш о собнтии, он просто добавлнет 
в список зкземплир типа делегата. Конечно, отказ от регистрации реализуетсл 
удалением соответствугогцего делегата. 

Обратите внимание: поле делегата (NewMail в нашем примере) всегда закрБ1тое, 
несмотрн на то что исходнаи строка кода определнет собБ1тие как открБ1тое. Зто 
делаетсл дли предотврагценгш некорректнвгх операции из кода, не относлгцегосл 
к определнгогцему классу. Если 6 бг поле 6 бшо открБ1ТБ1м, лгобои код мог 6 бг изме- 
нитб значение полн, в том числе удалитв все делегатБц подписавшиесл на собвгтие. 

Втораи конструкцгш, генерируемаи компилитором С#, — метод, позволчгогции 
другим oć'bc icia.vi регистрироватБСи в качестве получателеи уведомленил о со- 
6 б 1 тии. Компилнтор C# автоматически присваивает зтои функции имн, добавлнн 
приставку add_ к имени собљтш (NewMail). Компилнтор C# также автоматически 
генерирует код метода, которвги всегда вБгзвшает статическии метод Combine типа 
System.Delegate. Метод Combine добавлнет в список делегатов новбш зкземплнр 
и возврагцает новбги заголовок списка, которвги снова сохраниетсл в поле. 

ТретБл и последннн конструкцгш, генерируемал компилнтором С#, — метод, 
позволчгогции обвекту отказатвси от подписки на собБгеие. И зтои функции ком- 
пилнтор C# присваивает ими автоматически, добавлин приставку remove_K имени 
со 6 б!Т 1 ш (NewMail). Код метода всегдавБгзвшает метод Remove типа System . Delegate. 
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Последнии метод удалиет делегата из списка и возврагцает новми заголовок списка, 
которми сохраниетси в поле. 

ВНИМАНИЕ 

При попнтке удаленил метода, коториш не 6bm добавлен, метод Delegate.Remove 
не делает ничего. Bbi не получите ни исклкзченил, ни предупрежденил, а коллекцил 
методов cočbiTHH останетсл без изменении. 


ПРИМЕЧАНИЕ 

Оба метода — add и remove — исполизу 10 т хорошо известнми паттерн обновленил 
значенил способом, безопаснмм в отношении потоков. Зтот паттерн описмваетсл 
в главе 28. 


В приведенном примере методм add и remove обвнвленм открмтмми, посколб- 
ку в соответствукзгцеи строке исходного кода собмтие изпача./њпо обвивлено как 
открмтое. Если бм оно бмло обЂнвлено как загцигценное, то методм add и remove, 
сгенерированнме компилнтором, тоже бмли бм обЂнвленм как загцигценнме. Так 
что когда в типе определиетси собмтие, модификатор доступа собмтгш указмвает, 
какои код способен регистрироватЂСн и отменитЂ регистрациго дли уведомленгш 
о собмтии, но приммм доступом к полго делегата обладает толђко сам тип. Членм- 
собмтгш также могут о6ђивлитђси статическими и виртуалЂнмми; в зтом случае 
сгенерированнме компилитором методм add и remove также будут статическими 
или виртуалЂнмми соответственно. 

Помимо генерировангш зтих трех конструкцгш, компилиторм генериругот записв 
с определением собмтгш и помегцагот ее в метаданнме управлнемого модули. Зта 
записв содержит рнд флагов и базовми тип-делегат, а также ссмлки на методм до- 
ступа add и remove. Зта информации нужна просто длл того, чтобм очертитв свизђ 
между абстрактнмм понитием «собмтие» и его методами доступа. Зти метаданнме 
могут исполЂЗОватЂ компилчторм и другие инструментм, и, конечно же, зти сведенгш 
можно получитЂ при помогци класса System . Ref lection . Eventlnf о. Однако сама 
среда CLR зти метаданнме не исполнзует и во времи вмполненгш требует лишђ 
наличгш методов доступа. 


Создание типа, отслеживакнцего собнтие 

Самое трудное позади. В зто.ч разделе н покажу, как определитв тип, исполЂзуго- 
гции собмтие, поддерживаемое другим типом. Начнем с изученин исходного кода 
типа Fax: 

internal sealed class Fax { 

// Передаем конструктору обтаект MailManager 


продолжение & 
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public Fax(MailManager mm) { 

// Создаем зкземпллр делегата EventFlandlertNe^MailEventArgs^, 

// ccbmaminnncfl на метод обратного вузова FaxMsg 

// Регистрируем обратнми вмзов длл cočbiTnn NewMail обћекта MailManager 
mm.NewMail += FaxMsg; 

} 

// MailManager вузмвает зтот метод длл уведомленил 
// обиекта Fax о прибмтии нового почтового сообшенил 
private void FaxMsg(Object sender, NewMailEventArgs e) { 

// 'sender' исполизуетсл длл взаимодеиствил c обиектом MailManager, 

// если потребуетсл передатБ ему какут-то информацит 

// 'е' определнет дополнителцнук) информацик) о собмтии, 

// которунз пожелает предоставитц MailManager 

// Обмчно расположеннни здесц код отправллет сообшение по факсу 
// Тестовал реализацил вуводит информацит на консолц 
Console.WriteLine("Faxing mail message:"); 

Console.WriteLine(" From={0}, То={1}, Subject={2}", 
e.From, e.To, e.Subject); 

} 

// Зтот метод может вмполнлтцсл длн отмент регистрации обвекта Fax 
// в качестве получтелл уведомлении о соб^тии NewMail 
public void Unregister(MailManager mm) { 

// Отменитц регистрацит на уведомление о собмтии NewMail обцекта 
MailManager. mm.NewMail -= FaxMsg; 

} 

} 

При инициализации почтовое приложение сначала создает обвект MailManager 
и сохраниет ссмлку на него в переменнои. Затем оно создает обвект Fax, передаван 
ссмлку на MailManager как параметр. В конструкторе Fax обвект Fax регистрируетсн 
на уведомленгш о собмтии NewMail обвекта MailManager при помогци оператора += 
измка С#: 

mm.NewMail += FaxMsg; 

Обладаи встроеннои поддержкои собмтии, компиллтор C# транслирует опе- 
ратор += в код, регистрирукзгции обвект дли полученин уведомлении о собмтии: 

mm.add_NewMail(new EventFlandler<NewMailEventArgs>(this . FaxMsg) ) ; 

Как видите, компилитор C# генерирует код, конструирукнции делегата 
EventHandler<NewMailEventArgs>, которми инкапсулирует метод FaxMsg класса 
Fax. Затем компшштор C# вмзмвает метод add_NewMail обвекта MailManager, пере- 
даван ему нового делегата. Конечно, вм можете убедитБСи в зтом, скомпилировав 
код и затем изучив IL -код с no.viommo такого инструмента, как утилита ILDasm.exe. 
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Даже исполћзуи измк, не поддерживакшдии собмтин напрнмук), можно зареги- 
стрироватБ делегат длл уведомленгш о собмтии, нвно вмзвав метод доступа add. 
Резулкгат не изменнетсл, толбко исходнми текст получаетсл не столб злегантнмм. 
Именно метод add регистрирует делегата длл уведомленгш о собмтии, добавлии 
его в список делегатов данного собмтил. 

Когда срабатмвает собмтие обвекта MailManager, вмзвшаетсн метод FaxMsg о6ђ- 
екта Fax. Зтому методу в первом параметре sender передаетсн ссмлка на обвект 
MailManager. Чагце всего зтот параметр игнорируетсн, но он может и исполБЗОватЂ- 
сн, если в ответ на уведомление о собмтии обвект Fax пожелает получитБ доступ 
к поллм или методам обвекта MailManager. Второи параметр — ссмлка на обвект 
NewMailEventArgs. Зтот обвект содержит bcio дополнителБнук) информацшо, кото- 
рал, по мненшо NewMailEventArgs, может 6 мтђ полезнои длн получателеи собмтгш. 

При помогци обЂекта NewMailEventArgs метод FaxMsg может без труда получитк 
доступ к сведенгшм об отправителе и получателе сообгценгш, его теме и собственно 
тексту. РеалЂнми оођскт Fax отправллл бм зти сведенгш адресату, но в данном при- 
мере они просто вмводлтсл на консолђ. 

Когда обЂекту болкше не нужнм уведомленгш о собмтилх, он должен отменитв 
свого регистрациго. Например, оођскт Fax отменит свого регистрациго в качестве 
получателн уведомленгш о собмтии NewMail, если полвзователк) болвше не нужно 
пересмлатЂ сообгценгш злектроннои почтм по факсу. Пока оођскт зарегистриро- 
ван в качестве получателн уведомленгш о собмтии другого обнекта, он не будет 
уничтожен уборгциком мусора. Если в вашем типе реализован метод Dispose о6ђ- 
екта IDisposable, уничтожение обнекта должно вмзватЂ отмену его регистрации 
в качестве получателл уведомленгш обо всех собмтилх (об обвекте IDisposable 
см. также главу 21). 

Код, иллгостриругогции отмену регистрации, показан в исходном тексте метода 
Unregister обнскта Fax. Код зтого метода фактически идентичен конструктору 
типа Fax. Единственное отличие в том, что здесв вместо += исполвзован оператор 
-=. Обнаружив код, отменнгогции регистрациго делегата при помогци оператора -=, 
компилитор C# генерирует вмзов метода remove зтого собмтгш: 

mm.remove_NewMail(new EventHandler<NewMailEventArgs>(FaxMsg) ); 

Как и в случае оператора +=, даже при исполЂЗОвании нзмка, не поддерживаго- 
гцего собмтил напримуго, можно отменитв регистрациго делегата лвнмм вмзовом 
метода доступа r emove, которми отменнет регистрациго делегата путем сканировангш 
списка в поисках делегата-оболочки метода, соответствугогцего переданному. Если 
совпадение обнаружено, делегат удаллетсн из списка делегатов собмтгш. Если нет, 
то список делегатов собмтил остаетсл, а ошибка не происходит. 

Кстати, C# требует, чтобм дгш добавленгш и удаленгш делегатов из списка в ва- 
ших программах исполЂЗОвалисЂ операторм += и -=. Если попмтатЂСн напрнмуго 
обратитвсл к методам add или remove, компшштор C# сгенерирует сообгцение об 
ошибке (CS057 1: оператор или метод доступа нелкзи вмзмватЂ нвно): 

CS0571: cannot explicitly call operator or accessor 
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Лвное управление регистрациеи собмтии 

В типе System.Windows . Forms.Control определено около 70 собмтии. Если тип 
Control реализует собмтил, позволил компилитору нвно генерироватБ методБ 1 
доступа add и remove и поли-делегатБ1, то каждБ1и обвект Control будет иметк 
70 полеи-делегатов длн каждого собвпин! Так как многих программистов интересует 
относителБно неболБшое подмножество собвмии, дли каждого обвекта, созданного 
из производного от Control типа, огромнвш обвем памнти будет расходоватБСл 
напрасно. Кстати, типб 1 System . Web . UI. Control (из ASP.NET) и System. Windows. 
UIElement (из Windows Presentation Foundation, WPF) также предлагагот множество 
со 6 б 1 тии, i(oto|)i,ic болБшинство программистов не исполвзует. 

В зтом разделе рассказано о том, каким образом компилитор C# позволлет 
разработчикам реализоввшатв со 6 б 1 тил, управлии тем, как методБ 1 add и remove 
манипулиругот делегатами обратнБ1х вбгоовов. Л покажу, как нвнаи реализации со- 
6 б 1 тин помогает зффективно реализоватв класс с поддержкои множества со 6 б 1 тии. 
Впрочем, пвнан реализацин собвгтии типа может оказатвсн полезнои и в других 
ситуацинх. 

Длн зффективного храненгш делегатов собвгтии каждвги обвект, применнгогции 
собкгтгш, поддерживает коллекциго (обвшно зто словарв), в которои идентификатор 
собвгтил нвллетсл клгочом, а список делегатов — значением. При создании ново- 
го обвекта коллекцгш пуста. При регистрации собвгтил идентификатор собвгтил 
игцетсл в коллекции. Если идентификатор собвгтгш будет наиден, то новбш делегат 
добавлнетсл в список делегатов дли зтого собвгтгш. Если идентификатор собвгтгш 
не наиден, то он добавлиетсл к делегатам. 

При иницгшровангш собвгтил идентификатор собвгтил гггцетсл в коллекции. 
Если в коллекции нет соответствугогцего злемента, то собвгтие не регистрируетсл, 
а делегатвг не вБгзБгваготсн. Если же идентггфггкатор собвгтгш находитсн в коллекции, 
то вБгзБгваготсн делегатвг из спггска, ассоциированного с зтим идентификатором со- 
бвгтин. За реализациго зтого паттерна отвечает разработчик, которвги проектирует 
тип, определигогции собвгтил. Разработчик, исполБзугогции тип, обпгчно не имеет 
представленгш о внутреннеи реализации собвгтии. 

Прггведу прггмер возможнои реалггзацгги зтого паттерна. И реалггзовал класс 
EventSet, представлигогцгги коллекцггго собвгтии и спггсок делегатов каждого со- 
бвгтгш следугогцим образом: 
using System; 

using System.Collections.Generic; 
using System.Threading; 

// Зтот класс нужен длл поддержанил безопасности типа 
// и кода при исполнзовании EventSet 
public sealed class EventKey : Object { } 

public sealed class EventSet { 

// 3aKpbiTbin словарБ служит длл отображенил EventKey -> Delegate 
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private readonly Dictionary<EventKey, Delegate> m_events = 
newDictionary<EventKey, Delegate>(); 

// Добавление отображенил EventKey -> Delegate, если его не суцествует 
// И компоновка делегата с суцествунмцим клкјчом EventKey 
public void Add(EventKey eventKey, Delegate handler) { 

Monitor.Enter(m_events); 

Delegate d; 

m_events.TryGetValue(eventKey, out d); 

m_events[eventKey] = Delegate.Combine(d, handler); 

Monitor.Exit(m_events); 

} 

// Удаление делегата из EventKey (если он суцествует) 

// и разрнв свлзи EventKey -> Delegate при удалении 
// последнего делегата 

public void Remove(EventKey eventKey, Delegate handler) { 

Monitor.Enter(m_events); 

// Bbi30B TryGetValue предотврацает вмдачу исклтченин 

// при попнтке удаленил делегата с отсутствунлцим клкјчом EventKey. 

Delegate d; 

if (m_events.TryGetValue(eventKey, out d)) { 
d = Delegate.Remove(d, handler); 

// Если делегат остаетсл, то установити новми клнјч EventKey, 

// иначе - удалити EventKey 

if (d != null) m_events[eventKey] = d; 

else m_events.Remove(eventKey); 

} 

Monitor.Exit(m_events); 

} 

// Информирование o собмтии длл обозначенного клтча EventKey 
public void Raise(EventKey eventKey, Object sender, EventArgs e) { 

// He BbiflaeaTb исклтчение при отсутствии клтча EventKey 
Delegate d; 

Monitor.Enter(m_events); 
m_events.TryGetValue(eventKey, out d); 

Monitor.Exit(m_events); 

if (d != null) { 

// Из-за того что словари может содержати несколико разннх типов 
// делегатов, невозможно создати вцвов делегата, безопаснии по 
// отношениго к типу, во времл компиллции. R BbBbiBam метод 
// DynamicInvoke типа System.Delegate, передаван ему параметрш метода 
// обратного вшзова в виде массива обцектов. DynamicInvoke будет 
// контролироватц безопасностц типов параметров длл вшзмваемого 
// метода обратного BbBOBa. Если будет наидено несоответствие типов, 
// вмдаетсл исклтчение. 

d . DynamicInvoke(newObject [] { sender, е }); 

} 

} 
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Далее приведен пример класса, исполћзугошего класс EventSet. Зтот класс 
имеет поле, ссмлагогцеесл на обвект EventSet, и каждое собмтие из зтого класса 
реализуетсн нвно таким образом, что каждми метод add сохраннет заданного де- 
легата обратного вмзова в обвекте EventSet, а каждми метод remove уничтожает 
заданного делегата обратного вмзова (если наидет его). 
using System; 

// Определение типа, унаследованного от EventArgs длл атого собмтил 
public class FooEventArgs : EventArgs { } 

public class TypeWithLotsOfEvents { 

// Определение закрмтого зкземпллрного полл, сстлак)1цегосл на коллекцик). 

// Коллекцил управллет множеством пар "Event/Delegate" 

// Примечание: Тип EventSet не входит в FCL, 

// зто мои собственнми тип 

private readonly EventSet m_eventSet = newEventSet(); 

// Зашитенное своиство позволлет производнмм типам работати с коллекциеи 
protected EventSet EventSet { get { return m_eventSet; } } 

#region Code to support the Foo event (repeat this pattern for additional events) 
// Определение членов, необходимух длл собмтил Foo. 

// 2а. Создаите статическии, доступнми толцко длл чтенил обцект 
// длл идентификации собмтил. 

// Каждми обцект имеет свои хеш-код длл нахожденил свлзанного списка 
// делегатов собмтил в коллекции. 

protected static readonly EventKey s_fooEventKey = newEventKey(); 

// 2b. Определение длл собштил методов доступа длл добавленил 
// или удаленил делегата из коллекции. 
public event EventHandler<FooEventArgs> Foo { 
add { m_eventSet.Add(s_fooEventKey, value); } 
remove { m_eventSet.Remove(s_fooEventKey, value); } 

} 

// 2c. Определение зашишенного виртуалвного метода On длл зтого собштил. 
protected virtual void OnFoo(FooEventArgs e) { 
m_eventSet.Raise(s_fooEventKey, this, e); 

} 

// 2d. Определение метода, преобразукицего входнше даннше зтого собштил 

public void SimulateFoo( ) {OnFoo(newFooEventArgs() );} 

ttendregion 

} 


Программнми код, исполБзугогции тип TypeWithLotsOf Events, не может сказатБ, 
6 бшо ли собБ 1 тие реализовано неивно компилитором или нвно разработчиком. Он 
просто регистрирует со 6 б 1 тил с исполБЗОванием о 6 б 1 чного синтаксиса. Пример 
программного кода: 
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public sealed class Program { 
public static void Main() { 

TypeWithLotsOfEvents twle = new TypeWithLotsOfEvents(); 

// Добавление обратного вмзова 
twle.Foo += HandleFooEvent; 

// Провернем работоспособностн 
twle.SimulateFoo(); 

} 

private static void HandleFooEvent(object sender, FooEventArgs e) { 
Console.WriteLine("Handling Foo Event here..."); 

} 

} 



Глава 12. Обоб|ценив 


Разработчикам хорошо известнм достоинства обЂектно-ориентированного про- 
граммировангш. Одно из клгочевмх преимугцеств — возможностб многократного 
исполБЗОванин кода за счет создангш производнмх классов, наследугогцих все воз- 
можности базового класса. В производном классе можно просто переопределитБ 
виртуалБНБге методБг или добавитБ новбш методБг, что6бг изменитБ унаследованнБге 
от базового класса характеристики дли решенгш новбгх задач. Обобгценил (generics) — 
егце один механизм, поддерживаемБги средои CLR и нзБгками программировангш 
дли другои разновидности многократного исполвзовангш кода — а именно много- 
кратного исполБЗОвангш алгоритмов. 

По сути, разработчик описвшает алгоритм, например, сортировки, поиска, заме- 
нб1, сравненгш или преобразовангш, но не указвшает типбг даннБгх, с которвгми тот 
работает, что позволлет применитБ алгоритм к обЂектам разнкгх типов. Применни 
готовБги алгоритм, другои разработчик должен указатБ конкретнБге типбг даннвгх, 
например дли алгоритма сортировки — Int32, Stning и т. д., а дли алгоритма срав- 
ненгш — DateTime, Version и т. д. 

Болбшинство алгоритмов инкапсулировано в типе. CLR поддерживает создание 
как обобгценнБгх ссбшочнбгх, так и обобгценнБгх значимБгх типов, однако обобгцен- 
HBie перечислимБге типбг не поддерживаготсн. Кроме того, CLR позволнет создаватв 
обобгценнБге интерфеисБг и делегатов. Иногда полезнвш алгоритм инкапсулирован 
в одном методе, позтому CLR поддерживает создание обобгценнвгх методов, опреде- 
леннБгх в ссбшочном типе, в значимом типе или в интерфеисе. 

В частности, в библиотеке FCL определен обобгценнвш алгоритм управленгш 
списками, работагогции с набором обвектов. Тип обвектов в обобгценном алгорит- 
ме не указан. Разработчик, которвш хочет исполвзоватБ такои алгоритм, должен 
указатБ конкретнБш тип даннБгх. 

FCL -класс, инкапсулиругогции обобгценнвш алгоритм управленгш списками, на- 
звшаетсн List<T> иопределенвпространствеимен System.Collections .Genenic. 
Исходнбпг текст определенгш зтого класса вбгглидит следугогцим образом (приво- 
дггтси с сокрагценгшми): 

[Serializable] 

public class List<T> : IList<T>, ICollection<T>, IEnumerable<T>, 

IListj ICollection, IEnumerable { 

public List(); 

public void Add(T item); 

public Int32 BinarySearch(T item); 

public void Clear(); 
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public Boolean Contains(T item); 
public Int32 IndexOf(T item); 
public Boolean Remove(T item); 
public void Sort(); 

public void Sort(IComparer<T> comparer); 
public void Sort(Comparison<T> comparison); 
public T[] ToArray(); 

public Int32 Count { get; } 

public T this[Int32 index] { get; set; } 

} 

Символами <T> сразу после имени класса автор обобшенного класса List указал, 
что класс работает с неопределеннмм типом даннмх. При определении обобгценного 
типа или метода переменнме, указаннме вместо типа (например, Т), назмваготси 
параметрами типа (type parameters). Т — зто имн переменнои, которое применнетсн 
в исходном тексте во всех местах, где исполБзуетсл соответствугогции тип даннмх. 
Например, в определении класса List переменнан Т служит параметром (метод 
Add принимает параметр типа Т) и возврагцаеммм значением (метод ТоАггау воз- 
врагцает одномернми массив типа Т) метода. Другои пример — метод-индексатор 
(в C# он назмваетсл this). У индексатора естБ метод доступа get, возврагцагогции 
значение типа Т, и метод доступа set, получагогции параметр типа Т. Переменнуго Т 
можно исполБЗОватБ в лгобом месте, где должен указвшатвсн тип данннгх — а значит, 
и при определении локалБНБгх переменнБгх внутри метода или полеи внутри типа. 

ПРИМЕЧАНИЕ 

В рекомендацилх Microsoft длн проектировш,иков указано, что переменнБ 1 е пара- 
метров должнм назБ 1 ватБса Т или, в краинем случае, начинатБСл с Т (как, напри- 
мер, ТКеу или TValue). Т означает тип (type), а I означает интерфеис (например, 
IComparable). 


Итак, после определенгш обобгценного типа List<T> готовбш обобгценнБш ал- 
горитм могут исполБЗОватБ другие разработчики; длл зтого они просто указншагот 
конкретнБпг тип данннгх, с которБш должен работатн зтот алгоритм. В случае обоб- 
гценного типа или метода указаннБге типбг даннБгх назБшагот аргументами-типами 
(type arguments). Например, разработчик может исполБЗОватБ алгоритм List, указав 
тип DateTime в качестве аргумента-типа: 

private static void SomeMethod() { 

// Создание списка (List), работагацего с обБектами DateTime 
List<DateTime> dtList = new List<DateTime>(); 

// Добавление обБекта DateTime в список 
dtList.Add(DateTime.Now); // Без упаковки 

// Добавление еце одного обљекта DateTime в список 
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dtList.Add(DateTime.MinValue); // Без упаковки 

// Попмтка добавити обвект типа String в список 
dtList.Add("l/l/2004"); // Ошибка компиллции 

// Извлечение обцекта DateTime из списка 

DateTime dt = dtList[0]; // Приведение типов не требуетсл 

} 

На примере зтого кода виднм главнме преимугцества обобгцении длл разработ- 
чиков. 

□ Загцита исходного кода. Разработчику, исполБзугогцему обобгценнми алгоритм, 
не нужен доступ к исходному тексту алгоритма (при работе с гнаблонами С++ 
разработчику, исполБзугогцему алгоритм, необходим его исходнми текст). 

□ Безопасностћ типов. Когда обобгценнми алгоритм применнетсл с конкретнмм 
типом, компилитор и CLR понимагот зто и следлт за тем, чтобм в алгоритме 
исполБЗОвалисг> лигнб обЂектБг, совместимБге с зтим типом даннБгх. ПопБгтка ис- 
полБЗОванин несовместимого обвекта приведет к огнибке на зтапе компилиции 
или исклгоченшо во времн ввшолненгш. В нашем примере попБгтка передачи 
обвекта String методу Add вБгзБгвает ошибку компилнции. 

□ Более простои и понитнми код. Посколкку компилчтор обеспечивает безопас- 
ностб типов, в исходном тексте требуетсл менвше операцгш приведенгш типов, 
а такои код прогце писатв и сопровождатБ. В последнеи строке SomeMethod раз- 
работчику не нужно исполБЗОватБ приведение (DateT ime), чтобвг присвоитв пере- 
меннои dt резулБтат вБгзова индексатора (при запросе злемента с индексом 0). 

□ Повмшение производителБности. До понвленгш обобгцении один из способов 
определенгш обобгценного алгоритма заклгочалсн в таком определении всех его 
членов, чтобвг они <<умели» работатБ с типом даннБгх Object. Что6бг алгоритм 
работал с зкземплнрами значимого типа, перед вбгзовом членов алгоритма среда 
CLR должна бвша упаковатв зтот зкземплнр. Как показано в главе 5, упаковка 
требует вБгделенгш памнти в управлиемои куче, что приводит к более частвгм 
процедурам уборки мусора, а зто, в свого очередв, снижает производителБностБ 
приложенгш. Посколбку обобгценнБш алгоритм можно создатБ длл работБг 
с конкретнБш значимБш типом, зкземплнрБг значимого типа могут передаватБСн 
по значеншо и CLR не нужно вбшолннтб упаковку. Операции приведенгш типа 
также не нужнвг (см. предБгдугции пункт), позтому CLR не нужно контролироватБ 
безопасностБ типов при их преобразовании, что также ускорнет работу кода. 

Чтобвг убедитБ вас в том, что обобгценгш повБпнагот производителБностБ, л на- 
писал программу длл сравненгш производителвности необобгценного алгоритма 
ArrayList из библиотеки классов FCL и обобгценного алгоритма List. В ходе те- 
стировангш измернласБ производителБностБ алгоритмов с обБектами как значимБгх, 
так и ссБшочнБгх типов: 
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using System; 
using System.Collections; 
using System.Collections.Generic; 
using System.Diagnostics; 

public static class Program { 
public static void Main() { 

ValueTypePerfTest(); 

ReferenceTypePerfTest(); 

} 

private static void ValueTypePerfTest() { 
const Int32 count = 10000000; 

using (new OperationTimer("List<Int32>")) { 
List<Int32> 1 = new List<Int32>(); 
for (Int32 n = 0; n < count; n++) { 

l.Add(n); // Без упаковки 

Int32 х = l[n]; // Без распаковки 

} 

1 = null; // Длв удаленив в процессе уборки мусора 

} 

using (new OperationTimer("ArrayList of Int32")) { 
ArrayList a = new ArrayList(); 
for (Int32 n = 0; n < count; n++) { 
a.Add(n); // Упаковка 

Int32 х = (Int32) a[n]; // Распаковка 

} 

a = null; // Длв удаленив в процессе уборки мусора 

} 


private static void ReferenceTypePerfTest() { 

const Int32 count = 10000000; 

using (new OperationTimer("List<String>")) { 

List<String> 1 = new List<String>(); 
for (Int32 n = 0; n < count; n++) { 

l.Add("X"); // Копирование ссмлки 

String х = l[n]; // Копирование ссмлки 

} 

1 = null; // Длл удаленин в процессе уборки мусора 

} 

using (new OperationTimer("ArrayList of String")) { 

ArrayList a = new ArrayList(); 
for (Int32 n = 0; n < count; n++) { 

a.Add("X"); // Копирование ссмлки 

String х = (String) a[n]; // Проверка преобразованил 

} // и копирование сснлки 

а = null; // Длн удаленин в процессе уборки мусора 
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} 

} 

} 

// Класс длл оценки времени вмполненил операции 
internal sealed class OperationTimer : IDisposable { 
private Int64 m_startTime; 
private String m_text; 
private Int32 m_collectionCount; 

public OperationTimer(String text) { 

PrepareForOperation(); 

m_text = text; 

m_collectionCount = GC.CollectionCount(0); 

// Зта команда должна бнтц последнеи в зтом методе 
// длн максималцно точнои оценки бмстродеиствил 
m_startTime = Stopwatch.StartNew( ); 

} 

public void Dispose() { 

Console.WriteLine("{0} (GCs={l,3}) {2}", (m_stopwatch.Elapsed) л 
GC.CollectionCount(0) m_collectionCount, m_text); 

} 

private static void PrepareForOperation() { 

GC.Collect(); 

GC.WaitForPendingFinalizers(); 

GC.Collect(); 

} 


Скомпилировав зту программу в окончателг>нои версии (с вклгоченнои опти- 
мизациеи) и вмполнив ее на своем компБГОтере, и получил следугогции резулћтат; 

00:00:01.6246959 (GCs= 6) List<Int32> 

00:00:10.8555008 (GCs=390) ArrayList of Int32 

00:00:02.5427847 (GCs= 4) List<String> 

00:00:02.7944831 (GCs= 7) ArrayList of String 

Как видите, c типом Int32 обобшеннми алгоритм List работает гораздо бмстрее, 
чем необобгценнми алгоритм ArrayList. Более того, разница огромнан: 1,6 секундм 
против 11 секунд, то естБ в 7 раз бнлстрсс! Кроме того, исполБЗОвание значимого 
типа (Int32) с алгоритмом ArrayList требует множества операции упаковки, и, как 
резулћтат, 390 процедур уборки мусора, а в алгоритме List их всего 6. 

РезулвтатБ 1 тестированин длл ссбшочного типа не столб впечатлнгогцие: вре- 
меннБШ показатели и число операции уборки мусора здеск примерно одинаковБк 
Позтому в данном случае у обобгценного алгоритма List реалвнБ 1 х преимугцеств 
нет. Тем не менее помните, что применение обобгценного алгоритма значителвно 
упрогцает код и контролк типов при компилнции. Таким образом, хотн вБшгрБ 1 ша 
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в производителБности практически нет, обобш,еннвш алгоритм обмчно имеет 
и другие преимугцества. 

ПРИМЕЧАНИЕ 

Необходимо понимаљ, что CLR генерирует машиннми код дпл лкзбого метода при 
первом его вмзове в применении кконкретномутипуданнмх. Зто увеличивает размер 
рабочего набора приложенил и снижает производителвносљ. Подробнее об зтом 
Mbi поговорим чути позже в разделе «Инфраструктура обобш,ении». 


Обобшенил в библиотеке FCL 

Разумеетсн, обобгценин применнготси с классами коллекции, и в FCL определено не- 
сколбко таких обобгценнмх классов. Болбшинство зтих классов можно наити в про- 
странствах имен System.Collections.Genenic и System.Collections.ObjectModel. 
Также имеготсн безопаснме в отношении потоков классм коллекции в пространстве 
имен System . Collections . Concurrent. Microsoft рекомендует программистам от- 
казатБСи от необобгценнмх классов коллекции в по.њзу их обобгценнмх аналогов 
по несколцким причинам. Во-первмх, необобгценнме классм коллекции, в отличие 
от обобгценнмх, не обеспечивагот безопасностг. тггпов, простоту гг поннтностб кода 
и повБгшение проггзводителБности. Во-вторигх, обцектнан моделк у обобгценнБгх 
классов лучше, чем у необобгценнвгх. Например, у нггх менише вггртуалБНБгх мето- 
дов, что повБгшает проггзводггтелБностБ, а новБге членБг, добавленнБге в обобгценнвге 
коллекцгггг, добавлигот новуго функцггоналБностБ. 

КлассБг коллекции реалггзугот множество интерфеисов, а обвектБг, добавлнемБге 
в коллекцгггг, могут реализоввгватБ интерфеисБг, исполБзуемБге классамгг коллекции 
длл такггх операции, как сортировка и поггск. В составе FCL поставлнетсл множество 
определенгги обобгценнвгх ггнтерфеисов, позтому пргг работе с интерфеисами также 
доступнБг преггмугцества обобгценгш. Болбшггнство исполвзуемБгх ггнтерфеисов 
содержитси в пространствеимен System.Collections .Generic. 

Новвге обобгценнБге ггнтерфеисБг не заменнгот необобгценнБге: во многггх сггтуа- 
цинх прггходитси задеиствоватв оба вида интерфеисов. Причина — необходимоств 
сохраненгш обратнои совместимости. Например, еслгг 6бг класс List<T> реалггзо- 
вБгвал толбко ггнтерфеис IList<T>, в коде нелБЗи 6бгло 6бг рассматриватБ обвект 
List< DateTime> как IList. 

Также отмечу, что класс System.Array, базовкги дли всех тггпов массгг- 
вов, поддерживает множество статггческггх обобгценнБгх методов, в том чггсле 

AsReadOnly, BinarySearch,ConvertAll,Exists,Find,FindAll, Findlndex,FindLast, 
FindLastIndex, ForEach, IndexOf, LastIndexOf, Resize, Sort гг TrueForAll. Воткак 
вбггллдлт некоторБге ггз нггх: 

public abstract class Аггау : ICloneable, IList, ICollection, IEnumerable, 

IStructuralComparable, IStructuralEauatable { 


продолжение & 


308 Глава 12. Обобиденил 


public static void Sort<T>(T[] аггау); 

public static void Sort<T>(T[] аггау, IComparer<T> comparer); 

public static Int32 BinarySearch<T>(T[] аггау л T value); 
public static Int32 BinarySearch<T>(T[] arrayj T value, 
IComparer<T> comparer); 

} 


Следуклции код демонстрирует применение несколћких из зтих методов: 

public static void Main() { 

// Создание и инициализациа массива баитов 
Byte[] byteArray = new Byte[] { 5, 1 , 4, 2 , 3 }; 

// Bbi 30 B алгоритма сортировки Byte[] 

Аггау .Sort<Byte>(byteArray); 

// Bbi 30 B алгоритма двоичного поиска Byte[] 

Int32 i = Аггау .BinarySearch<Byte>(byteArray, 1); 

Console.WriteLine(i); // Внводит "0" 

} 


Инфраструктура обобшении 

Поддержка обобшении бмла добавлена в версшо 2.0 CLR, над ее реализациеи долго 

трудилосБ множество специалистов. Длн поддержанин работБ 1 обобгцении Microsoft 

нужно 6бшо сделатћ следугошее: 

□ СоздатБ новБге IL -командБ!, работагогцие с аргументами типа. 

□ ИзменитБ формат сугцествугогцих таблиц метаданнБ1х длл вБ1раженил имен 
типов и методов с обобгценнвши параметрами. 

□ ОбновитБ многие лзбгки программированин (в том числе С#, Microsoft Visual 
Basic .NET и др.), чтобвг обеспечитв поддержку нового синтаксиса и позволитб 
разработчикам определитБ и ссБглатБСи на новБге обобгценнБге типбг и методиг. 

□ ИзменитБ компилнторБг длн генерации иовбгх IL -команд и измененного формата 
метаданнБгх. 

□ ИзменитБ JIT -компилитор, чтобкг он обрабаткгвал новвге IL -командБг, работаго- 
гцие с аргументами типа, и создавал корректнвш машиннБги код. 

□ СоздатБ новБге членБг отраженин, чтобнг разработчики могли запрашиватБ ин- 
формациго о типах и членах, проверии у них наличие параметров. 

□ ОпределитБ новБге членБг, предоставлигогцие информациго отраженгш, чтобвг 
разработчики могли создаватв определенин обобгценнБгх типов и методов во 
времн исполнении. 
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□ ИзменитБ отладчик, что 6 б 1 он поддерживал обобш,еннБ1е типб1 , членБ 1 , полн 
и локалБНБШ переменнБге. 

□ ИзменитБ функциго IntelliSense в Microsoft Visual Studio длн отображенин кон- 
кретнБ1х прототипов членов при исполБЗОвании обобгценного типа или метода 
с указанием типа даннБ 1 х. 

А теперБ разберемсн, как обобшктшм реализуготсп во внутренних механизмах 
CLR. Зта информации пригодитсн вам как при проектировании и создании, так 
и при BBi6ope готовб1х обобгценнБ1х алгоритмов. 

OTKpbiTbie и закрмтме типн 

И уже рассказБшал, как CLR создает внутреннгого структуру даннвгх длл каждого 
типа, применнемого в приложении. Зти структурвг даннвгх назБшагот обЂектами- 
типами (type objects). ОбобгценнБпг тип также считаетсл типом, и длл него CLR 
тоже создает внутреннии обБект-тип. Зто справедливо длл ссбглочнбгх типов 
(классов), значимБгх типов (структур), интерфеисов и делегатов. Тем не менее тип 
с обобгценнБгми параметрами-типами назБгвагот откритим типом (open type), а в 
CLR запрегцено конструирование зкземплнров открвгтвгх типов (как и зкземплнров 
интерфеиснБгх типов). 

При ссвглке на обобгценнБги тип в коде можно определитв набор обобгценнБгх 
аргументов типа. Если всем аргументам определенного типа передаготсл деистви- 
телвнБге типбг ддннбгх, то он становитсл закритим типом (closed type). CLR раз- 
ренгает создание зкземплнров закрвгтвгх типов. Тем не менее в коде, ссБглагогцемси 
на обобгценнБш тип, можно не определитБ все обобгценнвге аргументБг типа. Таким 
образом, в CLR создаетсл новбш обвект откркгтого типа, зкземплирБг которого 
создаватБ нелБЗи. Следугогции код пронсниет ситуациго: 

using System; 

using System.Collections.Generic; 

// Частично определеннии открмтии тип 

internal sealed class DictionaryStringKey<TValue> : 

Dictionary<String., TValue> { 

} 

public static class Program { 
public static void Main() { 

Object o = nullj 

// Dictionary<,> - откритми тип c двумл параметрами типа 
Туре t = typeof(Dictionary< ,>); 

// Попитка созданил зкземпллра зтого типа (неудачнал) 
о = Createlnstance(t) ; 

Console.WriteLine(); 

// DictionaryStringKey<> - OTKpbiTbifi тип с одним параметром типа 

продолжение & 
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t = typeof(DictionaryStringKey<>); 

// Попнтка созданиа зкземпллра зтого типа (неудачнал) 
о = Createlnstance(t); 

Console.WriteLine(); 

// DictionaryStringKey<Guid> - зто закрнтни тип 
t = typeof(DictionaryStringKey<Guid>) ; 

// Погњггка созданил зкземпллра зтого типа (удачнал) 
о = Createlnstance(t) ; 

// Проверка успешности попмтки 
Console.WriteLine("Object type=" + o.GetType()); 

} 

private static Object CreateInstance(Type t) { 

Object o = null; 
try { 

o = Activator.Createlnstance(t); 

Console.Write("Created instance of {0}"j t.ToString()); 

} 

catch (ArgumentException e) { 

Console.WriteLine(e.Message); 

} 

return o; 

} 

} 


Если откомпилироватБ и вбшолнитб зтот код, Bbi увидите следуклцее: 

Cannot create an instance of System.Collections.Generic. 

Dictionary'2[TKey,TValue] because Type.ContainsGenericParameters is true. 

Cannot create an instance of DictionaryStringKey'l[TValue] because 
Type.ContainsGenericParameters is true. 

Created instance of DictionaryStringKey'l[System.Guid] 

Object type=DictionaryStringKey'l[System.Guid] 

Итак, при потлтке созданин зкземплнра открБ 1 того типа метод Createlnstance 
обвекта Activator вБвдает исклгочение ArgumentException. На самом деле сообгце- 
ние об исклгочении означает, что тип все егце содержит обобгценнБге параметрБ1 типа. 

В вБшодимои программои информации видно, что имена типов заканчиваготсн 
левои одиночнои кавБгчкои ('), за которои следует число, означагогцее арпоспњ 
(arity) типа, то естБ число необходимБгх длл него параметров типа. Например, ар- 
ностб класса Dictionary равна 2, потому что длн него требуетсл определитБ типб 1 
ТКеу и TValue. Арности класса DictionaryStringKey равна 1, так как требуетсл 
указатБ лишб один тип — TValue. 
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Необходимо отметитБ, что CLR размеидает статические полн типа в самом 
обЂекте-типе (см. главу 4). СледователБно, каждпш закрБдтБш тип имеет свои ста- 
тические полн. Иначе говорн, статические поли, определеннвге в обкекте List<T>, 
не будут совместно исполБЗОватБСп обвектами List<DateTime> и List<Stning>, 
потому что у каждого обкекта закрпдтого типа естп свои статические полн. Если же 
в обобгценном типе определен статическии конструктор (см. главу 8), то послед- 
нии вБшолниетсл длн закрндтого типа лишб раз. Иногда разработчики определигот 
статическии конструктор длп обобгценного типа, что6бд аргументБд типа соответ- 
ствовали определеннБш критеринм. Например, обобгценнБпг тип, исполБзуемБШ 
толбко с перечислимБши типами, определнетсл следугогцим образом: 

internal sealed class GenericTypeThatRequiresAnEnum<T> { 
static GenericTypeThatRequiresAnEnum() { 
if (!typeof(T).IsEnum) { 

throw new ArgumentException("T must be an enumerated type"); 

} 

} 

} 

B CLR сугцествует механизм ограниченип (constraints), предлагагогции более 
удачнБпг инструмент определенгш обобгценного типа с указанием допустимБгх 
длл него аргументов типа. Но об ограниченгшх — чутв позже. К сожалениго, зтот 
механизм не позволнет ограничитБ аргументБг типа толбко перечислимБши типами, 
позтому в предБгдугцем примере необходим статическии конструктор длн проверки 
того, что исполБзуемБш тип нвлнетсп перечислимБгм. 

Обоб|ценнме типм и наследование 

ОбобгценнБш тип, как и вснкии другои, может 6бгтб производнБш от других ти- 
пов. При исполБЗОвангш обобгценного типа с указанием аргументов типа в CLR 
определнетсл новбш обпект-тип, производнБпг от того же типа, что и обобгценнБш 
тип. Например, тип List<T> пвлиетсл производнвш от Object, позтому типбг 
List<Stning> н List<Guid> тожебудут производнБшиот Object. Аналогично, тип 
DictionanyStningKey<TValue> — производнБпг от Dictionany<Stning, TValue>, по- 
зтому тип DictionanyStningKey<Guid> также производнБш от Dictionany<Stning, 
Guid>. Понимание того, что определение аргументов типа не имеет ничего обгцего 
с иерархипми наследовангш, позволнет разобратвсп, какие приведенгш типов до- 
пустимБг, а какие нет. 

Например, пустБ класс Node свнзанного списка определпетсл следугогцим об- 
разом. 

internal sealed class Node<T> { 
public T m_data; 
public Node<T> m_next; 

public Node(T data) : this(data, null) { 

} 

продолжение & 
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public Node(T data, Node<T> next) { 
m_data = data; m_next = next; 

} 

public ovenride String ToString() { 
return m_data.ToString() + 

((m_next != null) ? m_next.ToString() : null); 

} 

} 

Тогда код создангш свизного списка будет вмглидетБ примерно так: 

private static void SameDataLinkedList() { 

Node<Char> head = new Node<Char>(' C'); 
head = new Node<Char>('B', head); 
head = new Node<Char>('A' л head); 

Console.WriteLine(head.ToString()); // Внводитсл "ABC" 

} 


B приведенном классе Node поле m_next должно ссБшатћси на другои узел, поле 
m_data которого содержит тот же тип дашшх. Зто значит, что узлБ1 свнзного списка 
должнб1 иметБ одинаковБш (или производнБди) тип даннБ1х. Например, нелБЗи ис- 
полБЗОватБ класс Node длн создангш свнзного списка, в котором тип даншчх одного 
злемента — Char, другого — DateTime, а третвего — String... Вернее, можно, если 
исполвзоватБ везде Node<Object>, но тогда mbi лишаемсл безопасности типов на 
стадии компилнции, а значимБ1е типб1 будут упаковБшатБСи. 

СледователБно, будет лучше начатБ с определенгш необобгценного базового 
класса Node, а затем определитв обобгценнБп! класс TypedNode (исполБзун класс Node 
как базовБпт). Такое решение позволнет создатв свнзнбп! список с произволБНБш 
типом даннБ1Х у каждого узла, полБЗОватБСи преимугцествами безопасности типов 
и избежатв упаковки значимБ 1 Х типов. Вот определенгш hobbix классов: 

internal class Node { 
protected Node m_next; 

public Node(Node next) { 
m_next = next; 

} 

} 

internal sealed class TypedNode<T> : Node { 
public T m_data; 

public TypedNode(T data) : this(data, null) { 

} 

public TypedNode(T data, Node next) : base(next) { 
m_data = data; 

} 


public override String ToString() { 
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return m_data.ToString() + 

((m_next != null) ? m_next.ToString() : String.Empty); 

} 

} 


Tenepb можно написатБ код дли создашш свнзного списка с разнмми типами 
даннмх у разнмх узлов. Код будет вмглндетБ примерно так: 

private static void DifferentDataLinkedList( ) { 

Node head = new TypedNode<Char>('.’); 

head = new TypedNode<DateTime>(DateTime.NoWj head); 

head = new TypedNode<String>("Today is ", head); 

Console.WriteLine(head.ToString()); 

} 

Идентификацил обоб|ценнмх типов 

Синтаксис обобгценнмх типов часто приводит разработчиков в замешателБСтво. 
В исходном коде понвлнетси слишком много знаков <<менвше» (<) и <<болБше» (>), 
и зто силбно затрудннет его чтение. Длн упрогценин синтаксиса некоторБге разработ- 
чики определнгот новбпг необобгценнБш тип класса, производнБ1и от обобгценного 
типа и определигогции все необходимБге аргументБ 1 типа. Например, пустБ нужно 
упроститБ следугогции код: 

List<DateTime> dt = new List<DateTime>(); 

НекоторБШ разработчики сначала определлт класс: 

internal sealed class DateTimeList : List<DateTime> { 

// ЗдесБ никакои код добавллтБ не нужно! 

} 

ТеперБ код созданич списка можно написатБ прогце (без знаков < и >): 
DateTimeList dt = new DateTimeList(); 

Зтот вариант удобен при исполБЗОвании нового типа длн параметров, локалБНБ1х 
переменнБгх и полеи. И все же ни в коем случае нелБЗн нвно определнтБ новбпг класс 
лишб затем, что 6 б 1 упроститБ чтение исходного текста. Причина проста: пропадает 
тождественностБ и зквивалентностБ типов, как видно из следугогцего кода: 

Boolean sameType = (typeof(List<DateTime>) == typeof(DateTimeList)); 

При вБшолненгш зтого кода sameType инициализируетсл значением f alse, по- 
тому что сравниваготси два обвекта раз. m>i х типов. Зто также значит, что методу, 
в прототипе которого определено, что он принимает значение типа DateTimeList, 
нелБЗи передатБ List<DateTime>. Тем не менее методу, которБш должен приниматБ 
List<DateTime>, можно передатБ DateTimeList, потому что тип DateTimeList чв- 
лнетсл производнБш от List<DateTime>. ЗапутатБСи в зтом оченБ просто. 

К счастБго, C# позволнет исполБЗОватБ упрогценнБш синтаксис длл ссбглки на 
обобгценнБш закрБ1ТБги тип, не влгшгогции на зквивалентностБ типов. Длл зтого 
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в начало фаила с исходнмм текстом нужно добавитБ старуго добруго директиву 

using: 

using DateTimeList = System.Collections.Generic.List<System.DateTime>; 

ЗдесБ директива using просто определлет символическое имм DateTimeList. 
При компилнции кода компилитор замениет все вхожденич DateTimeList типом 
Sy stem . Collections . Genenic . List<Sy stem. DateT ime>. Таким образом, разработ- 
чики могут исполБЗОватБ упрогценнБш синтаксис, не меннн смбдсл кода и тем самкш 
сохранни идентификациго и тождество типов. Теперв при ввшолнении следугошеи 
строки кода sameType инициализируетсл значением true: 

Boolean sameType = (typeof(List<DateTime>) == typeof(DateTimeList)); 

Длн удобства вбд можете исполБЗОватБ своиство локалвнои переменнои нелвного 
типа нзБдка С#, дли которои компилнтор обозначает тип локалкнои переменнои 
метода из типа вашего ввфажешш: 

using System; 

using System.Collections.Generic; 

internal sealed class SomeType { 
private static void SomeMethod () { 

// Компиллтор определлет, что dtl имеет тип 
// System.Collections.Generic.List<System.DateTime> 
var dtl = List<DateTime>(); 

} 

} 

Разрастание кода 

При JIT -компшшции обобгценного метода CLR подставлиет в IL -код метода 
указаннБШ аргументБ1-типБ1, а затем создает машиннБш код длн данного метода, 
работагогцего с конкретнкши типами даннБ1х. Зто именно то, что нужно, и зто одна 
из основнб 1 х функции обобгцении. Но в таком подходе еств один недостаток: CLR 
генерирует машиннБш код длл каждого сочетанин <<метод + тип», что приводит 
к разрастанит кода (code explosion); в итоге сугцественно увеличиваетсн рабочии 
набор приложенин, снижал производителБностБ. 

К счастБго, в CLR еств несколБКО механизмов оптимизации, призваннвгх предот- 
вратитБ разрастание кода. Во-первБгх, если метод вБгзБгваетсл длл конкретного 
аргумента типа и позже он вБгзвгваетсл опчтб с тем же аргументом типа, CLR ком- 
пилирует код длл такого сочетанин «метод + тип» толбко один раз. Позтому, если 
List<DateTime> исполБзуетсл в двух совершенно разнвгх сборках (загруженнкгх 
в один домен приложенгш), CLR компилирует методвг длн List<DateTime> всего 
один раз. Зто сугцественно сокрагцает степенв разрастанин кода. 
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Кроме того, CLR считает все аргументм ссмлочного типа тождественнмми, что 
опнтб же обеспечивает совместное исполБЗОвание кода. Например, код, скомпи- 
лированнми в CLR длн методов List<Stning>, может применнтвси дли методов 
List<Stream>, потому что Stning и Stream — ссмлочнме типм. По сути, дли всех 
ссмлочнмх типов исполБзуетсн одинаковми код. CLR вмполниет зту оптимизацшо, 
потому что все аргументм и переменнме ссмлочного типа — зто просто указатели 
на обвектм в куче (32-разрндное значение в 32-разрнднои и 64-разридное значение 
в 64-разриднои версии Windows), а все операции с указателлми на обвектм вм- 
полннготсл одинаково. 

Но если аргументм типа относнтсн к значимому типу, среда CLR должна сгене- 
рироватБ машиннБш код именно длл зтого значимого типа. Зто обЂнсннетсл тем, 
что у значимБ1х типов может 6 б1тб разнБш размер. И даже если два значимБ1х типа 
n.vieiOT одинаковБП! размер (например, Int32 и UInt32 — зто 32-разриднБ1е значе- 
нгш), CLR все равно не может исполБЗОватБ дли них единБш код, потому что дли 
обработки зтих значении могут применнтБСн разнБ1е .viaiiiiiinibie командБк 


Обоб|деннне интерфеисм 

Конечно же, основное преимугцество обобгцении — зто способностБ определлтБ 
ooooiueinibie ссбшочнбши значимБге типбк Но длн CLR такжеисклгочителБно важна 
поддержка обобгценнБ 1 х интерфеисов. Без них лгобан попБ1тка работБ 1 со значимБш 
типом через необобгценнБш интерфеис (например, ICompanable) вснкии раз будет 
приводитБ к необходимости упаковки и потере безопасности типов в процессе 
компилиции, что силбно сузило 6 bi областБ примененин o6o6iueiiiibix типов. Вот 
почему CLR поддерживает обобгценнБге интерфеисБк Ссбшочнбпт и зшчимбш типб 1 
реализугот обобгценнБп! интерфеис путем заданин аргументов-типов, или же лкзбои 
тип реализует обобгценнвш интерфеис, не задаван аргументБнтипБк Рассмотрим 
несколБКО примеров. 

Определение обобгценного интерфеиса из библиотеки FCL (из пространства 
имен System.Collections.Generic) вбилндит следугогцимобразом: 

public interface IEnumerator<T> : IDisposablej IEnumerator { 

T Current { get; } 

} 

Следукпции тип реализует даннБш обобгценнБП! интерфеис и задает аргументБ1 
типа. 

Обратите внимание, что обвект Tniangle может перечислнтБ набор обвектов 
Point, а своиство Cunnent имеет тип Point: 

internal sealed class Triangle : IEnumerator<Point> { 
private Point[] m_vertices; 

// Тип своиства Current в IEnumerator<Point> - ато Point 

продолжение # 
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public Point Current { get { ... } } 


} 

Tenepb рассмотрим пример типа, реализуготцего тот же обобгценнми интерфеис, 
но без задании аргументов-типов: 

internal sealed class ArrayEnumerator<T> : IEnumerator<T> { 
private T[] m_array; 

// Тип своиства Current в IEnumerator<T> - T 
public T Current { get { ... } } 


} 

Обратите внимание: обвект ArrayEnumerator перечислнет набор обвектов Т (где 
Т не задано, позтому код, исполБзугогции обобгценнми тип ArrayEnumerator, может 
задатБ тип Т позже). Также отмечу, что в зтом примере своиство Current имеет не- 
определеннми тип даннБгх Т. Подробнее обобгценнБге интерфеисБГ обсуждаготсн в 
главе 13. 


Обоб|деннБ1е делегатн 

Поддержка обобгценнБгх делегатов в CLR позволиет передаватБ методам обратного 
вБгзова лгобБге типбг обЂектов, обеспечивал при зтом безопасностБ типов. Более 
того, благодари обобгценнБгм делегатам зкземплнрБг значимого типа могут пере- 
даватБси методам обратного вБгзова без упаковки. Как уже отмечалосв в главе 17, 
делегат — зто просто определение класса с помогцбго четБгрех методов: конструк- 
тора и методов Invoke, Beginlnvoke и Endlnvoke. При определенгш типа делегата 
с параметрами типа компилитор задает методБг класса делегата, а параметрБг типа 
применнготсл ко всем методам, параметрБг и возврагцаемБге значенгш которигх от- 
носитсл к указанному параметру типа. 

Например, обобгценнБпг делегат определцетсл следугогцим образом: 

public delegate TReturn CallMe<TReturn, ТКеу, TValue>( 

ТКеу key, TValue value); 

Компшштор преврагцает его в класс, которБш на логическом уровне вбгглндит так: 

public sealed class CallMe<TReturn, ТКеу, TValue> : MulticastDelegate { 
public CallMe(Object object, IntPtr method); 
public virtual TReturn Invoke(TKey key, TValue value); 
public virtual IAsyncResult BeginInvoke(TKey key, TValue value, 

AsyncCallback callback, Object object); 
public virtual TReturn EndInvoke(IAsyncResult result); 

} 



Обобиденнне делегати 317 


ПРИМЕЧАНИЕ 

Там, где зто возможно, рекомендуетсн исполвзоватвобобш,еннв 1 хделегатов Action 
и Func из библиотеки FCL. Л описал зти Tnnbi делегатов в главе 17. 


Контравариантнне и ковариантнме аргументм-типм 
в делегатах и интерфеисах 

Каждми из параметров-типов обобшенного делегата должен бигп, помечен как 
ковариантнми или контравариантнми. Зто позволиет вам осугцествлнтБ приве- 
дение типа переменнои обобгценного делегата к тому же типу делегата с другим 
параметром-типом. Параметрм-типм могут бмтг>: 

□ Инвариантнмми. Параметр-тип не может изменнтБСи. Пока в зтои главе при- 
водилисб толбко инвариантнБге параметрБ1-типБ1. 

□ КонтравариантнБши. Параметр-тип может 6 бгтб преобразован от класса к классу, 
производному от него. В нзвгке C# контравариантнБш тип обозначаетсл к./почс- 
вб 1 м словом in. КонтравариантнБш параметр-тип может понвлнтбсн толбко во 
входнои позиции, например, в качестве аргументов метода. 

□ Ковариантнмми. Аргумент-тип может 6 бгтб преобразован от класса к одному 
из его базоввгх классов. В извгке C# ковариантнБпг тип обозначаетси клгочевБш 
словом out. КовариантнБпг параметр обобгценного типа может понвллтбсн толбко 
в вбгходнои позиции, например, в качестве возврагцаемого значенин метода. 

Предположим, что сугцествует следугогции тип делегата: 
public delegate TResult Funccin T, out TResult>(T arg); 

Здесв параметр-тип T помечен словом in, делагогцим его контравариантнвш, 
а параметр-тип TResult помечен словом out, делагогцим его ковариантнвш. 

ПустБ обБнвлена следугогцал переменнаи: 

FunccObject, AngumentException> fnl = null; 

Ee можно привести к типу Func с другими параметрами-типами: 

FunccString, Exception> fn2 = fnl; // Нвного приведенин типа не требуетсн 
Exception е = fn2(""); 

Зто говорит о том, что fnl ссвшаетсл на функцшо, котораи получает Object 
и возврагцает ArgumentException. Переменнан f n2 пвгтаетсл сослатБСн на метод, 
которнш получает Stning и возврагцает Exception. Так как мбг можем передатБ 
String методу, которому требуетсн тип Object (тип String нвллетсн производнвш 
от Object), а резулБтат метода, возврагцагогцего ArgumentException, может интер- 
претироватБСи как Exception (тип ArgumentException ивлнетсл производнвш от 
Exception), представленнБпг здесБ программнБпг код откомпилируетсн, а на зтапе 
компилнции будет сохранена безопасностк типов. 
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ПРИМЕЧАНИЕ 

Вариантносгњ деиствует тснљко в том случае, если компиллтор сможет установити 
возможноств преобразованил ссмлок между типами. Другими словами, вариант- 
HOCTb неприменима длл значиммх типов из-за необходимости упаковки (boxing). 
П считакз, что из-за зтого ограниченил вариантносњ суидественно терлет свокз по- 
лезносњ. Например: 

void ProcessCollection(IEnumerable<Object> collection) { ... } 

П не смогу Bbi3BaTb зтот метод, передавал ссмлку на обтсект List<DateTime> из-за 
невозможности ссмлочного преобразованил между значимим типом DateTime и o6b- 
ектом Object, даже если па1еЋтеунаследован OTo6beKTaObject. Можно решитизту 
проблему следукзидим образом: 

void ProcessCollection<T>(IEnumerable<T> collection) { ... } 

Bopbmoe преимуидество записи ProcessCollection(IEnumerable<Object> collection) 
заклкзчаетсл в том, что здесв исполвзуетсл толвко одна версил JIT -кода. Однако 
длл ProcessCollection<T> (IEnumerable<T> collection) тоже суидествует толико одна 
версил JIT -кода, совместно исполвзуемал всеми Т, чвллкзидимисл ccbmouHbiMH ти- 
пами. Длл Т, чвлч 1 оидихсл значимв 1 ми типами, будут генерироватисл другие версии 
JIT -кода, но по краинеи мере тепери можно вмзватв метод с передачеи ему коллекции 
значимого типа. 

Вариантносњтакже недопустима длл параметра-типа, если при передаче аргумента 
зтого типа исполизу 1 отсл KniOHeBbie слова out и ref. Например, длп строки: 

delegate void SomeDelegate<in T>(ref T t); 

компиллтор вндает следукоидее сообидение об ошибке (недеиствителвнал ва- 
риантности: параметр-тип Т' должен 6biTb инвариантно деиствителвнв 1 м длл 
’SomeDelegate<T>.lnvoke(ref Т)'. Параметр-тип Т' контравариантен): 

Invalid variance: The type parameter 'T' must be invariantly valid on 
'SomeDelegate<T>.Invoke(ref T)'. 'T' is contravariant 


Прп исполћзовании делегатов c обобпденними аргументами и возврагцаеммми 
значениими рекомендуетси всегда исполвзоватћ клдочевме слова in и out длл обо- 
значенин контравариантности и ковариантности везде, где зто возможно. Зто не 
приводит ни к каким нежелателмдмм последствинм, но позволит применнтБ ваших 
делегатов в болишем количестве сценариев. 

Как и в случае с делегатами, параметрм-типм интерфеисов могут 6мтб либо 
контравариантнмми, либо ковариантнмми. Приведу пример интерфеиса с контра- 
вариантнмм параметром обобгценного типа: 

public interface IEnumerator<out Т> : IEnumerator { 

Boolean MoveNext(); 

T Current { get; } 

} 

Контравариантноств T позволиет успешно скомпилироватБ и вмполнитб сле- 
дудогции программнми код: 
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// Зтот метод допускает интерфеис IEnumerable лтбого сснлочного типа 
Int32 Count(IEnumerable<Object> collection) { ... } 


// Зтот Bbi 30 B передает IEnumerable<String> в Count 
Int32 c = Count(new[] { "Grant" })j 


ВНИМАНИЕ 

Иногда разработчики спрашивакзт, почему они должнн пвно указвшатв слово in или 
out в параметрах обобиденного типа. Они полагакзт, что компилптор может само- 
столтелино проверитв обЂлвление делегатов или интерфеисов и автоматически 
определитЂ, лвлпкзтсл ли параметрм обобиденного типа контравариантннми или 
ковариантннми. Несмотрл на то что компиллтор деиствителЂно может зто опреде- 
ллтђ автоматически, разработчики лзнка C# считакзт, что при определении контракта 
следуетуказмватвзти слова в лвном виде. Представвте, что компиллтор определил, 
что параметр обобиденного типа контравариантен, а затем в будуидем в интерфеис 
будет добавлен член с параметром-типом в вмходнои позиции. В следуизидии раз 
при компилпции компиллтор определит, что зтот параметр-тип инвариантен, но в тех 
местах кода, где исполЂзуетсл факт контравариантности параметра-типа, могут 
возникнутЂ ошибки. 

По зтои причине разработчики компилптора требукзт точно определлтЂ параметр- 
тип. При попмтке исполЂЗОванил зтого параметра-типа в контексте, не соответ- 
ствукзидем обЂпвленикз, компиллтор вЂ1даст ошибку с сообидением о нарушении 
контракта. Если потом вм решите исправитв код путем добавленип in или out длп 
параметров-типов, вам придетсл внести измененил в программнни код, исполђ- 
зукзидии старни контракт. 


Обоб|деннне методн 

При определении обобпденного ссшлочного и значимого типа или интерфеиса 
все методм, определеннБде в зтих типах, могут исполБЗОватБ их параметр-тип. 
Параметр-тип может исполБЗОватБСи дли параметров метода, возврадцаемого 
значении метода или типа заданнои внутри него локалвнои переменнои. Но CLR 
также позволиет методу иметв собственнБде параметрБд-типБд, которБде могут при- 
менптБСн длл параметров, возврагцаемвдх значении или локалБНБдх переменнБдх. 
Вот немного искусственнБди пример типа, в котором определнкзтси параметр-тип 
и метод с собственнвдм параметром-типом: 

internal sealed class GenericType<T> { 
private T m_valuej 

public GenericType(T value) { m_value = value; } 

public TOutput Converter<TOutput>() { 

TOutput result = (TOutput) Convert.ChangeType(m_valuej typeof(TOutput)); 

продолжение & 


320 Глава 12. Обобиденил 


return result; 

} 

} 


Здесћ в классе GenenicType определлетсл свои параметр-тип (Т), а в методе 
Conventen — свои (TOutput). Благодарн зтому можно создатБ класс GenenicType, 
работагогции с лгобмм типом. Метод Conventen преобразует обвект, на которми 
ссмлаетси поле m_value, в другие типм в зависимости от аргумента типа, передан- 
ного ему при его вмзове. Возможностб определенин независимБдх параметров-типов 
и параметров метода дает небБшалуго гибкостБ. 

УдачнБди пример обобгценного метода — метод Swap: 

private static void Swap<T>(ref T ol, ref T o2) { 

T temp = ol; 
ol - o2; 
o2 = temp; 

} 

Теперп ББгзБшатБ Swap из кода можно следугогцим образом: 

private static void CallingSwap( ) { 

Int32 nl = 1, n2 = 2; 

Console.WriteLine("nl={0}, п2={1}", nl, n2); 

Swap<Int32>(ref nl, ref n2); 

Console.WriteLine("nl={0}, п2={1}", nl, n2); 

String sl = "Aidan", s2 = "Grant"; 

Console.WriteLine("sl={0}, s2={l}", sl, s2); 

Swap<String>(ref sl, ref s2); 

Console.WriteLine("sl={0}, s2={l}", sl, s2); 

} 

ИсполБЗОвание обобгценнБ 1 х типов c методами, получагогцими параметрвг out 
и nef , особенно интересно тем, что переменнвге, передаваемБге в качестве аргумента 
out/ nef , должнбг 6бгтб того же типа, что и параметр метода, чтобпг избежатБ возмож- 
ного нарушенгш безопасности типов. Зта особенноств параметров out/nef обсуж- 
даетсл в главе 9. В сугцности, именно позтому методвг Exchange и CompaneExchange 
класса Intenlocked поддерживагот обобгценнуго перегрузку 1 : 

public static class Interlocked { 

public static T Exchange<T>(ref T locationl, T value) where T: class; 
public static T CompareExchange<T>( 

ref T locationl, T value, T comparand) where T: class; 

} 

Обоб|ценнме методм и вмведение типов 

Синтаксис обобгцении в C# со всеми его знаками «менвше» и «болБше» приводит 
в замешателвство многих разработчиков. С целвго упроститБ создание, чтение и ра- 


1 


Клгочевое слово where описано в разделе «Верификацил и ограниченил» зтои главм. 
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боту с кодом компшштор C# предлагает логическое вшведение типов (type inference) 
при вмзове обобгценнмх методов. Зто значит, что компилнтор пмтаетси определитБ 
(или логически вмвести) тип, которми будет автоматически исполвзоватБСи при 
вмзове обобгценного метода. Логическии вмвод типов продемонстрирован в сле- 
дугошем фрагменте кода: 

private static void CallingSwapUsingInference( ) { 

Int32 nl = 1 , n2 = 2; 

Swap(ref nl, ref n2); // BbBbiBaeT Swap<Int32> 

String sl = "Aidan"; 

Object s2 = "Grant"; 

Swap(ref sl, ref s2); // Ошибка, невозможно вмвести тип 

} 

Обратите внимание, что в зтом коде при вмзове Swap аргументм типа не задаготсн 
с помогцбк) знаков < и >. В первом вмзове Swap компилитор C# сумел установитБ, 
что переменнБге nl и n2 относнтси к типу Int32, позтому он вБ13вал Swap, исполБзун 
аргумент-тип Int32. 

При вБшолнении логического вБшеденгш типа в C# исполвзуетсн тип даннБ 1 Х 
переменнои, а не фактическии тип обвекта, на KOTopnifi сскшаетсл зта переменнаи. 
Позтому во втором вБ130ве Swap компилитор C# «видит», что sl имеет тип String, 
а s2 — Object (хотл s2 ссБшаетсл на String). ПосколБку у переменнБ 1 х sl и s2 
разнБ1и тип даннБ1Х, компиллтор не может с точностбјо вБшести тип длл аргумента 
типа метода Swap и вБвдает ошибку (ошибка CS0411: аргументБ 1 типа длл метода 
Program.Swap<T>(ref Tj ref Т) немогут6 бтгб вБшеденБк Попробуитенвно задатп 
аргументБ1 типа): 

error CS0411: The type arguments for method 'Program.Swap<T>(ref T, ref T)' cannot 
be inferred from the usage. Тгу specifying the type arguments explicitly 

Тип может определнтБ несколБКО методов таким образом, что один из них будет 
приниматБ конкретнБш тип даннБ1Х, а другои — обобгценнБИ! параметр-тип, как 
в зтом примере: 

private static void Display(String s) { 

Console.WriteLine(s); 

} 

private static void Display<T>(T o) { 

Display(o.ToString()); // Вћвшвает Display(String) 

} 

Метод Display можно ввшватБ несколБКими способами: 

Display("leff "); // Вшзмвает Display(String) 

Display(123); // Вшзмвает Display<T>(T) 

Display<String>("Aidan"); // Вмзмвает Display<T>(T) 

B первом случае компилнтор может вБ13ватв либо метод Display, принимакпции 
String, либо обобгценнБш метод Display (заменнн Т типом String). Но компшштор 
C# всегда вБ 1 бирает нвное, а не обобгценное соответствие, позтому генерирует вб!ЗОв 
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необобдценного метода Display, получакнцего Stning. Во втором слЈлдае компилнтор 
не может вмзватБ необобгценнми метод Display, получагогции Stning, позтому он 
вмзмвает обобгценнми метод Display. Кстати, оченв удачно, что компилнтор всегда 
вмбирает более нвное соответствие. Ведг> если бм компилнтор вмбрал обобгценнми 
метод Display, тот вмзвал бм метод ToStning, возврагцагогции Stning, что привело 
бм к бесконечнои рекурсии. 

В третг>ем вћгзове метода Display задаетсч обобгценнБги аргумент типа Stning. 
Длл компиллтора зто означает, что не нужно пБгтатћсл логически вБгвести аргу- 
ментвг типа, а нужно исполБЗОватБ указаннБге аргументБг типа. В данном случае 
компилитор также считает, что непременно нужно внгзватБ обобгценнБш метод 
Display, позтому он его и вБгзБгвает. Внутреннии код обобгценного метода Display 
вБгзвгвает ToStning длн переданнои ему строки, а полученнан в резулвтате строка 
затем передаетсл необобгценному методу Display. 


Обоб|денил и другие членм 

В нзБгке C# у своиств, индексаторов, собвгтии, операторнвгх методов, конструкторов 
и деструкторов не может 6бгтб параметров-типов. Однако их можно определитв 
в обобгценном типе с тем, чтобвг в их коде исполвзоватБ параметрБг-типБг зтого 
типа. 

C# не поддерживает задание собственнвгх обобгценнвгх параметров типа у зтих 
членов, посколвку создатели нзкгка C# из компании Microsoft считагот, что раз- 
работчикам врид ли потребуетсл задеиствоватв зти членБг в качестве обобгценнвгх. 
К тому же длн поддержки обобгценного исполБЗОванин зтих членов в C# пригнлосБ 
6бг разработатБ специалБНБги синтаксис, что доволбно затратно. Например, при 
исполБЗОвании в коде оператора + компилнтор может ввгзватв перегруженнБш 
операторнБги метод. Невозможно указатв в коде, где еств оператор +, какие 6бг то 
ни 6бгло аргументБг типа. 


Верификацич и ограниченич 

В процессе компилнции обобгценного кода компилнтор C# анализирует его, убеж- 
дансБ, что он сможет работатн с лго6бгми типами данннгх — сугцествугогцими и теми, 
которвге будут определенБг в будугцем. Рассмотрим следугогции метод: 

private static Boolean MethodTakingAnyType<T>(T o) { 

T temp = o; 

Console.WriteLine(o.ToString()); 

Boolean b = temp.Equals(o); 
return b; 

} 
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ЗдесБ обЂнвлиетсл временнаи переменнаи (temp) типа Т, а затем ш.шолпиетси 
несколЂКО операции присваиванил переменншх и несколЂКО вшзовов методов. 
Представленнши метод работает с лгобшм типом Т — ссшлочншм, значимшм, пере- 
числимшм, типом интерфеиса или типом делегата, сугцествукнцим типом или типом, 
которши будет определен в будугцем, потому что лгобои тип поддерживает присва- 
ивание и вшзовш методов, определенншх в Object (например, ToStning и Equals). 
Вот егце метод: 

private static Т Min<T >(Т ol, Т о2) { 
if (ol . CompareTo(o2) < 0) return olj 
return o2; 

} 

Метод Min пштаетсн через переменнуго ol вшзватЂ метод CompaneTo. Но многие 
типш не поддерживагот метод CompaneTo, позтому компиллтор C# не в состоннии 
скомпилироватБ зтот код и обеспечитБ, чтобш после компилиции метод смог рабо- 
татБ со всеми типами. При попБ1тке скомпилироватБ приведеннБП! код понвитсн со- 
обшение об ошибке (ошибка CSOl 17: Т не содержит определение метода CompaneTo): 
error CS0117: 'Т' does not contain a definition for 'CompareTo' 

Получаетсн, что при исполБЗОвании обобгцении можно лишб о6блвллтб перемен- 
Hbie обобгценного типа, вбшолннтб присваивание, вБ 13 Б 1 ватБ методБц определеннБге 
в Object, — и все! Но ведБ в таком случае от обобгцении полбзбг мало. К счастБГО, 
компилиторБ1 и CLR поддерживагот уже упоминавшииси механизм ограниченип 
(constraints), благодари которому обобгценгш снова начинагот приноситБ практи- 
ческуго полБзу. 

Ограничение сужает переченБ типов, KOTopbie можно передатБ в обобгценном 
аргументе, и расширнет возможности по работе с зтими типами. Вот новбги вариант 
метода Min, которБш задает ограничение (вБвделено полужирнБш шрифтом): 

public static Т Min<T>(T ol, Т о2) where Т : IComparable<T> { 
if (ol . CompareTo(o2) < 0) return ol; 
return o2; 

} 

Маркер where в C# сообгцает компилнтору, что указаннБш в Т тип должен реа- 
лизовБшатБобобгценнБш интерфеис ICompanable того же типа (Т). Благодарн зтому 
ограничениго компилитор разрешает методу вБгзватБ метод CompaneT о, потому что 
последнии определен в интерфеисе ICompanable<T>. 

ТеперБ, когда код ссБшаетсн на обобгценнБги тип или метод, компилнтор должен 
убедитБСн, что в коде указан аргумент типа, удовлетворнгогции зтим ограниченгшм. 
Пример: 

private static void CallMin() { 

Object ol = "leff", o2 = "Richter"; 

Object oMin = Min<Object>(olj o2); // Ошибка CS0311 

} 
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При компиллции зтого кода понвлнетсн сообгцение (ошибка CS031 1: тип object 
не может исполБЗОватБСн в качестве параметра-типа ' Т' в обобгценном типе или 
методе 'SomeType.Min<T>(TjT) '. Несугцествуетненвногопреобразованин ссбшки 
из 'Object' в 'System.IComparable<object>'. 

Error CS0311: The type 'object’ cannot be used as type parameter 'T' in the generic 
type or method 'SomeType.Min<T>(T, T)’. There is no implicit 
reference conversion from 'object' to 'System.IComparable<object>'. 

Компилитор вБвдает зту ошибку, потому что System.Object не реализует ин- 
терфеис IComparable<Object>. Насамомделе System.Object вообшенереализует 
никаких интерфеисов. 

Итак, вб 1 примерно представлнете, что такое ограниченгш и как они работагот. 
Ограниченгш можно применитБ к параметрам типа как обобгценнБдх типов, так 
и обобгценнБдх методов (как показано в методе Min). Среда CLR не поддерживает 
перегрузку по именам параметров типа или по именам ограничении. Перегрузка 
типов и методов ввшолниетси толбко по арности. Покажу зто на примере: 

// Можно определитБ следукмцие типм: 
internal sealed class АТуре {} 
internal sealed class AType<T> {} 
internal sealed class АТуре<Т1, T2> {} 

// Ошибка: конфликт с типом АТуре<Т>, у которого нет ограничении. 
internal sealed class АТуре<Т> where Т : IComparable<T> {} 

// Ошибка: конфликт с типом АТуре<Т1, Т2> 
internal sealed class АТуре<ТЗ, Т4> {} 

internal sealed class AnotherType { 

// Можно определитБ следукицие методш: 
private static void M() {} 
private static void M<T>() {} 
private static void M<T1, T2>() {} 

// Ошибка: конфликт с типом М<Т>, у которого нет ограничении 
private static void М<Т>() where Т : IComparable<T> {} 


// Ошибка: конфликт с типом М<Т1, Т2>. 
private static void М<ТЗ, Т4>() {} 

} 

При переопределении виртуалБного обобгценного метода в переопределигогцем 
методе должно 6бгтб задано то же число параметров-типов, а они, в свого очередв, 
наследугот ограниченгш, заданнБге длл них методом базового класса. Собственно, 
переопределлемвш метод вообгце не вправе задаватв ограниченгш длл своих па- 
раметров-типов, но может переименовБшатв параметрБг-типБг Аналогично, при 
реализации интерфеисного метода в нем должно задаватвсп то же число параме- 
тров-типов, что и в интерфеисном методе, причем зти параметрвг-типБг наследугот 
ограниченгш, заданнБге длн них методом интерфеиса. Следугогции пример демон- 
стрирует зто правило с помогцбго виртуалБНБгх методов: 
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internal class Base { 

public virtual void McTlj T2>() 
where Т1 : struct 
where T2 : class { 

} 

} 

internal sealed class Derived : Base { 
public override void M<T3, T4>() 
where ТЗ : EventArgs // Ошибка 
where T4 : class // Ошибка 
{ } 

} 

При компилнции зтого кода попвитсл сообгцение об ошибке (ошибка CS0460: 
ограниченин длн методов интерфеисов с переопределением и нвнои реализациеи 
наследуготсл от базового метода и позтому не могут 6мтб заданм ивно): 

Error CS0460: Constraints for override and explicit interface implementation 
methods are inherited from the base method, so they cannot be 
specified directly 

Если из метода M<T3, Т4> класса Derived убратБ две строки where, код успешно 
компилируетсн. ЗаметБте: разрешаетсл переименовБшатБ параметрБг типа (в зтом 
примере ими Т1 изменено на ТЗ, а Т2 — на Т4), но изменнтв (и даже задаватБ) огра- 
ниченгш нелБЗи. 

ТеперБ поговорим о различнвгх типах ограничении, которБге компилнтор и CLR 
позволнгот применнтБ к параметрам типа. К параметру-типу могут применнтБСл 
следугошие ограниченгш: основное (primary), дополнителтое (secondary) и/или 
ограничение конструктора (constructor constraint). РечБ о них идет в следуклцих 
трех разделах. 


OcHOBHbie ограниченил 

В параметре-типе можно задатв не более одного основного ограничешш. Основнбш 
ограничением может 6 бгтб ссбшочнбги тип, указБшагогции на незапечатаннБш класс. 
НелБЗи исполБЗОватБ длл зтои цели следугогцие ссбшочнбш типбк System.Object, 
System.Array, System.Delegate, System.MulticastDelegate, System.ValueType, 
System.Enum и System.Void. 

При задании ограниченгш ссбшочного типа вбг гарантируете компилнтору, что 
заданнБп! аргумент-тип будет относитбсн либо к типу, указанному в ограничении, 
либо к производному от него типу. Длн примера возвмем следугогции обобгценнБги 
класс: 

internal sealed class PrimaryConstraintOfStream<T> where T : Stream { 
public void M(T stream) { 
stream.Close();// OK 
} 

} 
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В зтом определении класса длл параметра-типа Т установлено основное огра- 
ничение Stream (из пространства имен System.IO), сообгцагогцее компиллтору, что 
код, исполвзугогции PrimaryConstraintOfStream, должен задаватБ аргумент типа 
Stream или производного от него типа (например, FileStream). Если параметр-тип 
не задает основное ограничение, автоматически задаетси тип System .Object. Однако 
если в исходном тексте нвно указатБ System . Ob ject, компилнтор C# вкддаст ошибку 
(ошибка CS0702: в ограничении не может исполвзоватБСн специалБНБШ класс ob ject): 

error CS0702: Constraint cannot be special class 'object' 

Естб два особвгх основнбдх ограниченгш: class и struct. Ограничеиие class 
гарантирует компилитору, что указашљш аргумент-тип будет иметн ссбшочнбпг 
тип. Зтому ограничениго удовлетворнгот все типБ1-классБ1, типБ1-интерфеисБ1, типбт- 
делегатБ1 и типБ1-массивБ1, как в следугогцем обобгценном классе: 

internal sealed class PrimaryConstraintOfClass<T> where T : class { 
public void M() { 

T temp = null;// ДопустимОЈ потому что тип Т должен 6biTb ссилочнмм 

} 

} 

В зтом примере присваивание temp значенгш null допустимо, потому что из- 
вестно, что Т имеет ссбшочнбш тип, а лгобаи переменнан ссбшочного типа может 
6б1тб равна null. При отсутствии у Т ограничении зтот код 6 bi не скомпилировал- 
сн, потому что тип Т мог 6 bi 6бшб значимБш, а переменнБге значимого типа нелБЗи 
приравннтБ к null. 

Ограничение struct гарантирует компилитору, что указанннш аргумент типа 
будет иметБ значимБш тип. Зтому ограничениго удовлетворнгот все значимвге 
типБг, а также перечисленил. Однако компилнтор и CLR рассматривагот лгобои 
значимБги тип System . Nullable<T> как особкш, и значимБге типбг с поддержкои 
null не подходлт под зто ограничение. Зто обљжчшетсз тем, что длл параметра 
типа Nullable<T> деиствует ограничение struct, а среда CLR запрегцает такие 
рекурсивнБге типбг, как Nullable<Nullable<T>>. Значимкге типбг с поддержкои 
null обсуждаготсл в главе 19. 

Пример класса, в котором параметр-тип ограничиваетсл клгочеввгм словом 
struct: 

internal sealed class PrimaryConstraintOfStruct<T> where T : struct { 
public static T Factory() { 

// ДопускаетслЈ потому что у каждого значимого типа нелвно 
// ecTb открутми конструктор без параметров 
return new Т(); 

} 

} 

В зтом примере применение к Т оператора new правомерно, потому что известно, 
что Т имеет значимвш тип, а у всех значимвгх типов ненвно еств открБгтБпг конструк- 
тор без параметров. Если 6 бг тип Т 6 бш неограниченнБш, ограниченнБш ссбшочнбш 
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типом или ограниченнмм классом, зтот код не скомпилировалсн бм, потому что 
у некотормх ссмлочнмх типов нет открмтмх конструкторов без параметров. 


ДополнителБНме ограниченин 

Длн параметра-типа могут 6 мтб заданм пу. њ или более дополнителБнмх ограниче- 
нии. При задании ограниченин интерфеисного типа вм гарантируете компилнтору, 
что указаннми аргумент-тип будет определнтБ тип, реализугогции зтот интерфеис. 
А так как можно задатБ несколБКО интерфеиснБгх ограничении, в аргументе типа 
должен указБшатћсн тип, реализугогции все интерфеиснБге ограниченил (и все 
основнБге ограниченгш, если они заданБг). Подробнее об интерфеиснБгх ограниче- 
нгшх см. главу 13. 

Другои тип дополнителБНБгх ограничении назБшагот ограничением параметра- 
типа (type parameter constraint). Оно исполБзуетсл гораздо реже, чем интерфеиснБге 
ограниченгш интерфеиса, и позволнет обобгценному типу или методу указатв, что 
аргументБ1-типБ1 должнбг 6бгтб свлзанБг определеннБши отношенгшми. К параметру- 
типу может 6 бгтб применено нулн и более ограничении. В следугогцем обобгценном 
методе продемонстрировано исполвзование ограниченгш параметра-типа: 

private static List<TBase> ConvertIList<T, TBase>(IList<T> list) 
where T : TBase { 

List<TBase> baseList = new List<TBase>(list.Count); 
for (Int 32 index = 0 ; index < list.Count; index++) { 
baseList.Add(list[index]); 

} 

return baseList; 

} 

B методе ConvertlList определенБг два параметра-типа, из которвгх параметр Т 
ограничен параметром типа TBase. Зто значит, что какои 6 бг аргумент-тип ни 6 бш 
задан дли Т, он должен 6 бгтб совместим с аргументом-типом, заданнвш дли TBase. 
В следугогцем методе показанБг допустимБге и недопустимБге вбгзовбг Convertl List: 

private static void CallingConvertIList() { 

// Создает и инициализирует тип List<String> (реализукмции IList<String>) 
IList<String> ls = new List<String>(); 
ls.Add("A String"); 

// Преобразует IList<String> в IList<Object> 

IList<Object> lo = ConvertIList<String, Object>(ls); 

// Преобразует IList<String> в IList<IComparable> 

IList<IComparable> lc = ConvertIList<String, IComparable>(ls); 

// Преобразует IList<String> в IList<IComparable<String>> 
IList<IComparable<String>> lcs = 

ConvertIList<String, IComparable<String>>(ls); 

// Преобразует IList<String> в IList<String> 

IList<String> ls 2 = ConvertIList<String, String>(ls); 


продолжение & 
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// Преобразует IList<String> в IList<Exception> 

IList<Exception> le = ConvertIList<String, Exception>(ls); // Ошибка 

} 

B первом вмзове ConvertlList компилитор провериет, чтобм тип String бмл 
совместим с Object. ПосколБку тип String нвлнетсн производнмм от Object, первми 
вмзов удовлетворнет ограниченшо параметра-типа. Во втором вмзове ConvertlList 
компилнтор провернет, чтобм тип String бмл совместим с IComparable. ПосколБку 
String реализует интерфеис IComparable, второи вмзов соответствует ограниченшо 
параметра-типа. В третћем вмзове ConvertlList компилнтор провернет, чтобм тип 
String бмл совместим с IComparable<String>. Так как String реализует интерфеис 
IComparable<String>, третии вмзов соответствует ограниченшо параметра-типа. 
В четвертом вмзове ConvertlList компилнтор знает, что тип String совместим сам 
ссобои. В пнтом вмзове ConvertlList компилнтор провернет, чтобм тип String бмл 
совместим с Exception. Однако так как тип String несовместим с Exception, пнтми 
вмзов не соответствует ограниченшо параметра типа, и компиллтор возврагцает 
ошибку (ошибка CS0311: тип stringHe может исполБЗОватБСл в качестве параметра- 
типа ' Т' в обобшенном типе или методе Program . Convertl List<T , ТВа se> (System. 
Collectons .Generic .IList<T>).He сушествует ненвного преобразовангш ссмлки 
из 'string' в 'System.Exception ': 

ernon CS 0311 : The type 'string' cannot be used as type parameter 'T' in the 
generic type or method Program.ConvertIList<T,TBase>(System.Collections.Ge 
neric.IList<T>)’. There is no implicit reference conversion from 'string' to 
’System.Exception'. 


Ограниченил конструктора 

Дли параметра-типа можно задатБ не более одного ограниченгш конструктора. 
Ограничение конструктора гарантирует компилнтору, что указаннБп! аргумент-тип 
будет иметБ неабстрактнБш тип, имегогции открБ1ТБ1и конструктор без параметров. 
Учтите, что компшштор C# считает ошибкои одновременное задание ограниченгш 
конструктора и ограниченгш struct, потому что зто избвгточно. У всех значимБ 1 х 
типов неивно присутствует otkpbitbiii конструктор без параметров. В следугогцем 
классе дли параметра-типа исполвзовано ограничение конструктора: 

internal sealed class ConstructorConstraint<T> where T : new() { 
public static T Factory() { 

// Допустимо, потому что у всех значиммх типов неввно 

// ecTb oTKpbiTbifi конструктор без параметров, и потому что 

// зто ограничение требует, чтобш у всех указанншх ссшлочншх типов 

// также бшл открштши конструктор без параметров 

return new Т(); 

} 

} 


В зтом примере применение оператора new к Т допустимо, потому что из- 
вестно, что Т — зто тип с открвгтм конструктором без параметров. Разумеетси, 
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зто справедливо длн всех значиммх типов, а ограничение конструктора требует, 
чтобм зто условие вмполннлосб и дли всех ссмлочнмх типов, заданнмх в аргу- 
менте-типе. 

Иногда разработчики предпочитагот о6ђлвллтг> параметр типа через ограничение 
конструктора, при котором сам конструктор принимает различнме параметрм. На 
сегоднншнии денв CLR (и, как следствие, компилитор С#) поддерживает толђко 
конструкторм без параметров. По мненшо специалистов Microsoft, в болЂшинстве 
случаев зтого вполне достаточно, и н с ними полностђго согласен. 


Другие проблемм верификации 

В оставшеисн части зтои главм н представлго нссколђко конструкции, которме из-за 
проблем с верификациеи при исполЂЗОвании обобгцении ведут себн непредсказуемо, 
и покажу, как с помогцђго ограничении сделатБ их верифицируеммми. 

Приведение переменнои обобшенного типа 

Приведение переменнои обобгценного типа к другому типу допускаетсн толбко 
в том случае, если она приводитсн к типу, совместимому с ограничением: 

private static void CastingAGenericTypeVariablel<T>(T obj) { 

Int32 х = (Int32) obj ; // Ошибка 

String s = (String) obj; // Ошибка 

} 

Компилитор вернет ошибку длн обеих строк, потому что Т может иметћ лгобои 
тип и успех приведенгш типа не гарантирован. Чтобм зтот код скомпилировалсн, 
его нужно изменитБ, добавив в начале приведение к Object: 

private static void CastingAGenericTypeVariable2<T>(T obj) { 

Int32 х = (Int32) (Object) obj ; // Ошибки нет 

String s = (String) (Object) obj; // Ошибки нет 

} 


ТеперБ зтот код скомпилируетсл, но во времн вмполненгш CLR все равно может 
сгенерироватБ исклгочение InvalidCastException. 

Дли приведенгш к ссБшочному типу также применнгот оператор as изБгка С#. 
В следугогцем коде он исполБзуетсл с типом String (посколбку Int32 — значимБпг 
тип): 

private static void CastingAGenericTypeVariable3<T>(T obj) { 

String s = obj as String; // Ошибки нет 

} 

Присваивание переменнои обобгценного типа значенил 
по умолчаник) 

Приравнивание переменнои обобгценного типа к null допустимо, толбко если 
обобгценнБш тип ограничен ссбшочнбгм типом: 



330 Глава 12. Обобиденил 


private static void SettingAGenericTypeVariableToNull<T>() { 

T temp = null; // CS0403: нелвзп привести null к параметру типа Т 
// because it could be a value type... 

// (Ошибка CS0403: нелизл привести null к параметру типа Т, 

// поскол bKy Т может имети значимми тип...) 

} 

Так как параметр типа Т не ограничен, он может иметБ значимћш тип, а при- 
равннтБ переменнуго значимого типа к null нелБЗл. Если 6бд параметр типа Т 
6бш ограничен ссбшочнбш типом, temp можно 6бшо 6бд приравннтБ к null, и код 
скомпилировалсн 6бд и работал. При создании C# в Microsoft посчитали, что раз- 
работчикам может понадобитвсн присвоитБ переменнои значение по умолчаншо. 
Дли зтого в компилиторе C# предусмотрено клкзчевое слово def ault: 

private static void SettingAGenericTypeVariableToDefaultValue<T>() { 

T temp = default(T); // Работает 

} 

B зтом примере клкзчевое слово default приказвшает компилптору C# и JIT- 
компилнтору CLR создатк код, приравнивакзгции temp к null, если Т имеет cci>i- 
лочнбди тип, и обнулнкзгции все 6 итб 1 переменнои temp, если Т имеет значимБш тип. 

Сравнение переменнои обоб|денного типа с null 

Сравнение переменнои обобгценного типа с null с помогцбкз операторов == и ! = 
допустимо независимо от того, ограничен обобгценнвш тип или нет: 

private static void ComparingAGenericTypeVariableWithNull<T>(T obj) { 
if (obj == null) 

{ /* Зтот код никогда не исполнлетсл длл значимого типа */ } 

} 

Так как тип Т не ограничен, он может 6 бдтб ссбшочнбш или знлчимбш. Во вто- 
ром случае obj пе.њзи приравннтв null. 06бдчно в зтом случае компилитор C# 
должен вввдатБ ошибку, но зтого не происходит — код успешно компилируетсл. 
При вБдзове зтого метода с аргументом значимого типа JIT -компилнтор, обнару- 
жив, что резулвтат вБшолненгш инструкции if никогда не равен true, просто не 
сгенерирует машиннБш код длл инструкции if и кода в фигурнвдх скобках. Если 
6ki а исполБЗОвал оператор ! =, JIT -компилнтор также не сгенерировал 6бд код длн 
инструкции if (посколБку условие всегда истинно), но сгенерировал 6бд код в фи- 
гурнБдх скобках после if . 

Кстати, если к Т применитБ ограничение struct, компилнтор C# вкддаст ошибку, 
потому что код, сравнивакзгции значимвги тип с null, не имеет смншла — резулБтат 
всегда один. 

Сравнение двух переменншх обобшенного типа 

Сравнение двух переменнБ1х одинакового обобгценного типа допустимо толбко 
в том случае, если обобгценнвш параметр типа имеет ссбшочнбш тип: 



Верификации и ограниченил 331 


private static void ComparingTwoGenericTypeVariables<T>(T ol, T o2) { 
if (ol == o2) { } // Ошибка 

} 


B зтом примере у Т нет ограничении, и хотн можно сравниватБ две переменнме 
ссбшочного типа, сравниватБ две переменнвге значимого типа допустимо лишб в том 
случае, когда значимвш тип перегружает оператор ==. Если у Т еств ограничение 
class, зтот код скомпилируетсл, а оператор == вернет значение true, если пере- 
меннвге ссБшаготсл на один обвект и полиостбго тождественнБк Если параметр Т 
ограничен ссбшочнбш типом, перегружагогцим метод operator==, компиллтор 
сгенерирует isi.i.soisi.i зтого метода в тех местах, где он встречает оператор ==. Есте- 
ственно, зто относитсл и к оператору ! =. 

Прн написании кода длн сравненин злементарнвгх значимБгх типов (Byte, Int32, 
Single, Decimal и т. д.) компилитор C# сгенерирует код правилвно, но дли непри- 
МИТИВНБ 1 Х значимБгх типов генерироватв код сравненин он не умеет. Позтому если у 
параметраТ метода ComparingTwoGenericTypeVariables еств ограничение struct, 
компилнтор вБгдаст ошибку. А ограничиватБ параметр-тип значимнш типом нелнзн, 
потому что они неивно нвлиготсч запечатаннвши, а следователБно, не сугцествует 
типов, производнБгх от значимого типа. Если 6hi зто 6бшо разрешено, обобгценнБш 
метод будет ограничен конкретннш типом; компилнтор C# не позволнет зто делатв, 
посколБку зффективнее бвшо 6bi исполвзоватБ iicoooomeiiiu.iii метод. 

Исполизование переменних обоб^ценного типа в качестве операндов 

Следует заметитБ, что исполБЗОвание операторов с операндами обобгценного типа 
создает немало проблем. В главе 5 н показал, как C# обрабатвшает примитивнвге 
типБ 1 — Byte, Intl6, Int32, Int64, Decimal и др. B частности, н отметил, что C# умеет 
интерпретироватБ onepaTopi.i, применнемБге к злементарнкш типам (например +, 
-, * и / ). Однако зти onepaTopi.i нелкзн исполБЗОватБ с переменнБши обобгценного 
типа, потому что во времл компилнции компиллтор не знает их тип. Получаетсл, 
что нелвзн спроектироватБ математическии алгоритм длн произволБНБ1х числовбш 
типов даннБ1х. Допустим, и попБ1тагосБ написатБ следугогции обобгценнБП! метод: 

private static Т Sum<T>(T num) where T : struct { 

T sum = default(T) ; 
for (T n = default(T) ; n < num ; n++) 
sum += n; 
return sum; 

} 

И сделал все возможное, чтобвг он скомпилировалсн: определил ограничение 
struct длл Т и исполвзовал конструкциго default(T), чтобвг sum и n инициализи- 
ровалисБ нулем. Но при компгшнцгш кода вБгдаготси три сообгценгш об ошибках: 

□ ошибка CS0019: оператор < нелкзи применнтБ к операндам типа Т и Т: 

error CS0019: Operator ’<’ cannot be applied to operands 
of type 'T' and 'T' 
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□ ошибка CS0023: оператор ++ нелБЗи применнтћ к операнду типа Т: 

error CS0023: Operator '++' cannot be applied to operand of type 'T' 

□ ошибка CS0019: оператор += нелБЗи применитБ к операндам типа Т и Т: 

error CS0019: Operator ’+=’ cannot be applied to operands 
of type 'T' and 'T' 

Зто супдественно ограничивает поддержку обобгцении в среде CLR, и многие 
разработчики (особенно из научнвдх, финансовБдх и математических областеи) 
испБ1тали глубокое разочарование. Многие пвдталисБ создатБ методБ1, призваннБде 
обоити зто ограничение, прибегал к отражениго (см. главу 23), примитивному 
типу dynamic (см. главу 5), перегрузке операторов и т. п. Однако все зти решенил 
силбно снижагот производителБностБ или ухудшагот читабелБностБ кода. Остаетсл 
надентБСл, что в следугогцих версилх CLR и компилнторов компанил Microsoft 
устранит зтот недостаток. 
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Многие программистм знакоми 1 с концепциеи множественного наследованин 
(multiple inheritance) — возможности определенин класса, производного от двух или 
более базовмх классов. Допустим, имеетси класс Т ransmitData, предназначеннми 
длл передачи даннмх, и класс ReceiveData, обеспечивагогции получение даннмх. 
Допустим, нужно создатБ класс SocketPort, которБш может и получатћ, и пере- 
даватБ даннБге. Длл зтого класс SocketPort должен наследоватБ одновременно от 
обоих классов: TransmitData и ReceiveData. 

НекоторБ1е избши программировании разрешагот множественное наследова- 
ние, позволии создатБ класс SocketPort, производнБш от двух базовБ1х классов. 
Однако CLR (а значит, и все основаннБ1е на зтои среде избжи программировангш) 
множественное наследование не поддерживает. Вместе с тем CLR позволнет реали- 
зоватБ ограниченное множественное наследование через интерфепси (interfaces). 
В зтои главе рассказБшаетси об определении и примененгш интерфеисов, а также 
приводлтси основнБге правила, позволигогцие поннтб, когда уместно исполБЗОватБ 
интерфеисБ!, а не базовБге классБт 


Наследование в классах и интерфеисах 

В .NET Framework естБ класс System.Object, в котором определено 4 открБптлх 
зкземплирнБгх метода: ToString, Equals, GetHashCode и GetType. Зтот классивлн- 
етсл корневБш базовБш классом длл всех осталБнвгх классов, позтому все классвг 
наследугот зти четБфе метода класса Object. Зто также означает, что код, оперируго- 
гции зкземплиром класса Object, в деиствителБности может вбшолннтб операции 
с зкземплнром лгобого класса. 

Лгобои производнБН! от Object класс наследует: 

□ СигнатурБГ методов. Зто позволнет коду считатБ, что он оперирует зкземплнром 
класса Object, тогда как на самом деле он работает с зкземплпром какого-либо 
другого класса. 

□ Реализациго зтих методов. Разработчик может определитв класс, производнБги 
от Object, не реализуи методвг класса Object вручнуго. 

В CLR у класса может 6 б 1 тб один и толбко один примои <<родителБ» (которБги 
примо или опосредованно наследует от класса Object). ВазовБш класс предостав- 
лиет набор сигнатур и реализацгш зтих методов. При зтом новбпг класс может статБ 
базовБш дли другого класса, которБп! будет определен другим разработчиком, и при 
зтом HOBbiii производнБш класс унаследует все сигнатурв! методов и их реализации. 
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CLR также позволиет определитБ интерфепс, которБпз, в сутцности, представ- 
лжт собои средство назначенип имени набору сигнатур методов. Интерфеис не 
содержит реализации методов. Класс наследует интерфеис через указание имени 
последнего, причем зтот класс должен нвно содержатБ реализации интерфеиснБ1х 
методов — иначе CLR посчитает определение типа недеиствителвнБш. Конечно, 
реализацин интерфеиснБ1х методов — обвино доволбно утомителБное заннтие, 
позтому л и назвал наследование интерфеисов ограниченнвш механизмом реали- 
зации множественного наследовангш. Компилнтор C# и CLR позволшот классу 
наследоватв от несколБких интерфеисов, и, конечно же, класс при зтом должен 
реализоватв все унаследованнвге методвг интерфеисов. 

Одна из замечателвнБгх особенностеи наследовангш классов — возможностб под- 
становки зкземплнров производного типа в лгобвге контекствг, в которвгх ввгступагот 
зкземплнрБг базового типа. Аналогичнвгм образом наследование от интерфеисов по- 
зволнет подставлнтв зкземплирБг типа, реализугогцего интерфеис, во все контекствг, 
где требуготсн зкземплнрБг указанного интерфеисного типа. Что6бг наше обсуждение 
стало более конкретннгм, даваите посмотрим, как определнготсн интерфеисвг. 


Определение интерфеисов 

Как упоминалосБ ранее, интерфеис представлнет собои именованнвги набор сигнатур 
методов. Обратите внимание, что в интерфеисах можно также определнтв со6бгтгш, 
своиства — без параметров или с ними (последние в C# назвгвагот индексаторами), 
посколвку все зто просто упрогценнБге средства синтаксиса, которвге в конечном 
итоге все равно соответствугот методам. Однако в интерфеисе нелвзи определитБ 
ни конструкторнг, ни зкземплнрнБге полн. 

Хотл CLR допускает наличие в интерфеисах статических методов, статических 
полеи и конструкторов, а также констант, CLS -совместимвш интерфеис не может 
иметБ подобнБгх статических членов, посколвку некоторкге нзбгкгг не поддерживагот 
их определение или обрагцение к ним. C# не позволиет определнтв в интерфеисе 
статические членвг. 

В C# длл определенин интерфеиса, назначенин ему имени и набора сигнатур 
зкземплнрнБгхметодов исполвзуетсл клгочевое слово intenface. Вот определенгш 
некоторвгх интерфеисов из библиотеки классов Framework Class Library: 

public interface IDisposable { 
void Dispose(); 

} 

public interface IEnumerable { 

IEnumenator GetEnumerator(); 

} 


public interface IEnumerable<T> : IEnumerable { 
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IEnumerator<T> GetEnumerator( ); 

} 

public interface ICollection<T> : IEnumerable<T>, IEnumerable { 
void Add(T item); 
void Clear(); 

Boolean Contains(T item); 

void CopyTo(T[] аггау, Int32 arraylndex); 

Boolean Remove(T item); 

Int32 Count { get; } // Своиство толвко длл чтенил 

Boolean IsReadOnly { get; } // Своиство толико длв чтенил 

} 

С точки зрешш CLR, определение интерфеиса — почти то же, что и определение 
типа. То естћ CLR определнет внутреннкно структуру даннБ1х длл обвекта интер- 
феисного типа, а длн обрагценин к различнкш членам интерфеиса может исполбзо- 
ватБ отражение. Как и тишл, интерфеис может определитБСн на уровне фаилов или 
6 б 1 тб вложеннБш в другои тип. При определении интерфеисного типа можно указатв 
требуемуго областБ видимости и доступа (public, protected, internal и т. п.). 

В соответствии с соглашением имена интерфеиснБ 1 х типов начинаготси с про- 
писнои буквБ 1 I, что облегчает их поиск в исходном коде. CLR поддерживает 
обобгценнБ1е интерфеисБ1 (как показано в некоторБ1х предБвдугцих примерах) и ин- 
терфеиснБге методБ 1 . В зтои главе н лишб слегка касагоск некоторБгх возможностеи 
обобгценнБ1х интерфеисов, детали см. в главе 12. 

Определение интерфеиса может «наследоватв» другие интерфеисБт Однако сло- 
во «наследоватБ» не совсем точное, посколвку в интерфеисах наследование работает 
иначе, чем в классах. И предпочитаго рассматриватв наследование интерфеисов как 
вклгочение контрактов других интерфеисов. Например, определение интерфеиса 
TCollection<T> вклгочает контракт интерфеисов TEnumerable<T> и IEnumerable. 
Зто означает следуклцее: 

□ лгобои класс, наследугогции интерфеис ICollection<T>, должен реализоватв 
все методБ1, определеннБ1е в интерфеисах ICollection<T>, IEnumerable<T> 
и IEnumerable; 

□ лгобои код, ожидагогции обвект, тип которого реализует интерфеис ICollection<T >, 
может 6 б 1 тб уверен в том, что тип обвекта также реализует методБ1 интерфеисов 

IEnumerable<T> и IEnumerable. 
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Сеичас и покажу, как определитв тип, реализугогции интерфеис, создатн зкземплнр 
зтого типа и исполБЗОватБ полученнБпг обвект дли внгзова интерфеиснБгх методов. 
В C# зто делаетсл оченв просто, внутренннн реализацгш чутв сложнее, но об зтом — 


немного позже. 



336 Глава 13. Интерфеисм 


Интерфеис System. ICompanable<T> определнетсл так (в MSCorLib.dll): 

public interface IComparable<T> { 

Int32 CompareTo(T other); 

} 


Следуклции код демонстрирует, как определитБ тип, реализуклции зтот интер- 
феис, и код, сравниваклции два обвекта Point: 

using System; 

// ОбБект Point лвллетса производнум от System.Object 
// и реализует IComparable<T> в Point 
public sealed class Point : IComparable<Point> { 
private Int32 m_x, m_y; 

public Point(Int32 х, Int32 у) { 
m_x = х; 
т_У = у; 

} 

// Зтот метод реализует IComparable<T> в Point 
public Int32 CompareTo(Point other) { 

return Math.Sign(Math.Sqrt(m_x * m_x + m_y * m_y) 

- Math.Sqrt(other.m_x * other.m_x + other.m_y * other.m_y)); 

} 

public override String ToStringO { 

return String.Format("({0}, {1})", m_x, m_y); 

} 

} 

public static class Program { 
public static void Main() { 

Point[] points = new Point[] { 
new Point(3, 3), 
new Point(l, 2), 

}; 


// Bbi30B метода CompareTo интерфеиса IComparable<T> обБекта Point 
if (points[0].CompareTo(points[1]) > 0) { 

Point tempPoint = points[0]; 
points[0] = points[l]; 
points[l] = tempPoint; 

} 

Console.WriteLine("Points from closest to (0, 0) to farthest:"); 
foreach (Point p in points) 

Console.WriteLine(p); 

} 


Компилнтор C# требует, что 6 б 1 метод, реализугошии интерфеис, отмечалсл 
модификатором public. CLR требует, чтобћ! интерфеиснБге методБ! 6 б 1 ли виртуалБ- 
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нмми. Если метод нвно не определен в коде как виртуалБнми, компилитор сделает 
его таковмм и, вдобавок, запечатаннмм. Зто не позволлет производному классу 
переопределитБ интерфеиснБге методБ1. Если нвно задатв метод как виртуалБНБпт, 
компилнтор сделает его таковкш и оставит незапечатаннвш, что предоставит про- 
изводному классу возможностб переопределлтБ интерфеиснБге методБ1. 

ПроизводнБш класс не в состолнии переопределнтв интерфеиснБ1е методБ 1 , 
обЂнвленнБге запечатаннБши, но может повторно унаследоватв тот же интерфеис 
и предоставитБ собственнуго реализациго его методов. При ввгеове интерфеисного 
метода обвекта ввгоБшаетсл реализацгш, свнзаннан с типом самого обвекта. Сле- 
дугогции пример демонстрирует зто: 

using System; 

public static class Program { 
public static void Main() { 

nepBbiPj пример 'i c: i :: i c 'i € 'i :: i''i c: i : 5 i c 'i c: i' 5 i c 'i c: i :: i c 'i € 'i :: i c 'i c: i' 5 i''i c: i : 5 t''i c j 

Base b = new Base(); 

// Вћ 1 зов реализации Dispose в типе b: "Dispose класса Base" 
b.Dispose(); 

// Вмзов реализации Dispose в типе обцекта b: "Dispose класса Base" 

((IDisposable)b).Dispose(); 

0 i-QpQ^j пример : i :: f :: i :: i :: f : 5 i :: i :: f :: f :: i :: f : 5 i :: i :: f : 5 i :: i :: f : 5 i :: i :: f :: i :: i :: f : 5 i : j 

Derived d = new Derived(); 

// Вћ 1 зов реализации Dispose в типе d: "Dispose класса Derived" 
d.Dispose(); 

// Вмзов реализации Dispose в типе обцекта d: "Dispose класса Derived" 

((IDisposable)d).Dispose(); 

"Рр 0 "]~ии пример : i :: f :: i :: i :: f :: i :: i :: t :: f :: i :: f : 5 i :: i :: f :: i :: i :: f : 5 i :: i :: t :: i :: i :: f : 5 i :: i : ^ 

b = new Derived(); 

// Вмзов реализации Dispose в типе b: "Dispose класса Base" 
b.Dispose(); 

// Вузов реализации Dispose в типе обцекта b: "Dispose класса Derived" 
((IDisposable)b).Dispose(); 

} 

} 

// Зтот класс лвллетсл производнмм от Object и реализует IDisposable 
internal class Base : IDisposable { 

// Зтот метод нелвно запечатан и его нелцзл переопределитц 
public void Dispose() { 

Console.WriteLine("Base’s Dispose"); 

} 

} 

продолжение & 
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// Зтот класс наследует от Base и повторно реализует IDisposable 
internal class Derived : Base, IDisposable { 

// Зтот метод не может переопределити Dispose из Base. 

// Клкзчевое слово 'new' указмвает на то, что зтот метод 
// повторно реализует метод Dispose интерфеиса IDisposable 
new public void Dispose() { 

Console.WriteLine("Derived’s Dispose"); 

// ПРИМЕЧАНИЕ: следуклцал строка кода показувает, 

// как вмзватБ реализацик) базового класса (если нужно) 

// base.Dispose(); 

} 

} 

Подробнее о вмзовах 
интерфеиснБ1х методов 

Тип System . Stning из библиотеки FCL наследует сигнатурм и реализации ме- 
тодов System.Object. Кроме того, тип String реализует несколмсо интерфеисов: 
IComparable, ICloneable, IConvertible, IEnumerable, IComparable<String>, 
IEnumerable<Char> и IEquatable<String>. Зто значит, что типу String не требу- 
етсл реализовмватБ (или переопределнтБ) методБ1, имекжциесл в его базовом типе 
Object. Однако тип String должен реализоввшатв мстодрч, обБнвленнБ 1 е во всех 
интерфеисах. 

CLR допускает определение полеи, параметров или локалвнБ 1 х переменнБ 1 х, 
имекнцих интерфеиснБП! тип. ИсполБзун переменнуго интерфеисного типа, можно 
ББ13БшатБ методБц определеннБге зтим интерфеисом. К тому же CLR позволиет bbi- 
звшатБ методБц определеннБ1е в типе Object, посколвку все классБ1 наследугот его 
методБц как продемонстрировано в следугогцем коде: 

// Переменнал s ссилаетсл на обцект String 
String s = "Deffrey"; 

// Исполцзул переменнук) s, можно BbBNBaTb лкзбои метод, 

// определеннии в String, Object, IComparable, ICloneable, 

// IConvertible, IEnumerable и т. д. 

// Переменнал cloneable ссмлаетсл на тот же обцект String 
ICloneable cloneable = s; 

// Исполцзул переменнукз cloneable, л могу вћвватц лтбои метод, 

// обцлвленнии толбко в интерфеисе ICloneable (или лкзбои метод, 

// определеннии в типе Object) 

// Переменнал comparable ссилаетсл на тот же обцект String 
IComparable comparable = s; 

// Исполћзул переменнук) comparable, н могу вћвватц лтбои метод, 

// обцлвленнии толцко в интерфеисе IComparable (или лгабои метод, 

// определеннми в типе Object) 
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// Переменнан enumerable ссмлаетсл на тот же обвект String 
// Во времл внполненил можно приводитв интерфеиснук) переменнук) 

// к интерфеису другого типа., если тип обБекта реализует оба интерфеиса 

IEnumerable enumerable = (IEnumerable) comparablej 

// Исполизул переменнун) enumerable, л могу BbBtiBaTb лтбои метод, 

// обталвленнни толико в интерфеисе IEnumerable (или лгабои метод, 

// определеннни толико в типе Object) 

Все переменнме в зтом коде ссмлаготсн на один обвект String в управлиемои 
куче, а значит, лгобои метод, которми и вмзмваго с исполћзованием лгобои из зтих 
переменнмх, задеиствует один обвект String, храплтии строку " Deff геуНо тип 
переменнои определлет деиствие, которое н могу вмполнитб с обвектом. Перемен- 
нан s имеет тип String, значит, она позволнет вмзватћ лгобои член, определеннми в 
типе String (например, своиство Length). Переменнуго s можно также исполБЗОватБ 
длл вБ130ва лго 6 б 1 х методов, унаследованнБ 1 х от типа Object (например, GetType). 

Переменнаи cloneable имеет тип интерфеиса ICloneable, а значит, позволиет 
вБИБшатБ метод Clone, определеннБш в зтом интерфеисе. Кроме того, можно вбн 
зватБ лгобои метод, определешњш в типе Object (например, GetType), посколвку 
CLR «знает», что все типб 1 нвлнготсн производнвши от Object. Однако переменнан 
cloneable не позволнет ввгоБшатБ открБМБге методБ1, определеннБте в лгобом другом 
интерфеисе, реализованном типом String. Аналогичнвш образом через перемен- 
нуго comparable можно вБИватБ CompareTo или лгобои метод, определеннБП! в типе 
Object, но не другие методБк 


ВНИМАНИЕ 

Как и ссилочнми тип, значимми тип может реализоватБ несколБко (или нугљ) интер- 
феисов. Но при приведении зкземпллра значимого типа к интерфеисному типу зтот 
зкземпллр надо упаковатБ, потому что интерфеиснал переменнал лвллетсл сснлкои, 
которал должна указБ 1 ватБ на обвект в куче, чтобн среда CLR могла провериш ука- 
зателБ и точно вБтсниш тип обвекта. Затем при вмзове метода интерфеиса с упа- 
кованнБ 1 м значим^ 1 м типом CLR исполБзуетуказателБ, чтобм наити таблицу методов 
типа обвекта и Bbi3BaTb нужнми метод. 


^BHbie и нелвнме реализации интерфеиснмх 
методов (что происходит за кулисами) 

Когда тип загружаетси в CLR, длл него создаетси и инициализируетсн таблица 
методов (см. главу 1). Она содержит по однои записи длн каждого нового, представ- 
лнемого толбко зтим типом метода, а также записи дли всех виртуалБНБ1х методов, 
унаследованнБ1х типом. УнаследованнБге виртуалБНБге методБ1 вклгочагот методБ1, 
определеннБге в базоввш типах иерархии наследовангш, а также все методБц опреде- 
леннБге интерфеиснБши типами. Допустим, имеетси простое определение типа: 
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internal sealed class SimpleType : IDisposable { 

public void Dispose() { Console.WriteLine("Dispose"); } 

} 

Тогда таблица методов типа содержит записи, в котормх представленм: 

□ все зкземплнрнме методм, определеннме в типе Ob ject и нелвно унаследованнме 
от зтого базового класса; 

□ все интерфеиснме методм, определеннме в нвно унаследованном интерфеисе 
IDisposable (в нашем примере в интерфеисе IDisposable определен толбко 
один метод — Dispose); 

□ новми метод, Dispose, понвившиисн в типе SimpleType. 

Чтобм упроститБ жизнв программиста, компиллтор C# считает, что понвив- 
шииси в типе SimpleType метод Dispose нвллетсл реализациеи метода Dispose из 
интерфеиса IDisposable. Компиллтор C# вправе сделатБ такое предположение, 
потому что метод открћггБш, а сигнатурБ1 интерфеисного метода и нового метода 
совпадагот. Значит, методвг принимагот и возврагцагот одинаковвш типбг. Кстати, 
если 6 б 1 новбп! метод Dispose 6 бш помечен как виртуалБНБпг, компилитор C# все 
равно сопоставил 6 бг зтот метод с одноименнБгм интерфеиснБгм методом. 

Сопоставлнн новбпг метод с интерфеиснБш методом, компилнтор C# генерирует 
метаданнБге, указБгвагогцие на то, что обе записи в таблице методов типа SimpleType 
должнбг ссБглатБСн на одну реализациго. Что 6 бг вам стало поннтнее, следугогции код 
демонстрирует вбгзов открвгтого метода Dispose класса, а также вбгзов реализации 
класса длн метода Dispose интерфеиса IDisposable. 

public sealed class Program { 
public static void Main() { 

SimpleType st = new SimpleType(); 

// BbBOB реализации открмтого метода Dispose 
st.Dispose(); 

// Вћ 1 зов реализации метода Dispose интерфеиса IDisposable 
IDisposable d = st; 
d.Dispose(); 

} 

} 

B первом ввгзове вБшолннетсл обрагцение к методу Dispose, определенно- 
му в типе SimpleType. Затем и определлго переменнуго d интерфеисного типа 
IDisposable. Л инициализируго переменнуго d ссбшкои на обвект SimpleType. 
Теперк при вБгзове d . Dispose () вБгполннетсл обрагцение к методу Dispose интер- 
феиса IDisposable. Так как C# требует, чтобкг открбгтбш метод Dispose тоже 6 бш 
реализациеи длл метода Dispose интерфеиса IDisposable, будет вБгполнен тот же 
код, и в зтом примере вбг не заметите какои-либо разницБг. На вБгходе получим 
следугогцее: 
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Dispose 

Dispose 

Tenepb мм перепишем SimpleType, чтобм можно бмло увидети разницу: 

internal sealed class SimpleType : IDisposable { 

public void Dispose() { Console.WriteLine("public Dispose"); } 

void IDisposable.Dispose() { Console.WriteLine("IDisposable Dispose"); } 

} 

He вмзмван метод Main, мм можем просто перекомпилироватв и запустити за- 
ново программу, и на вмходе получим следуклцее: 

public Dispose 
IDisposable Dispose 

Если в C# перед именем метода указано имн интерфеиса, в котором определен 
зтот метод (в нашем примере — IDisposable . Dispose), то вм создаете лвнутреа- 
лизацит интерфепсного метода (Explicit Interface Method Implementation, EIMI). 
Заметше: при ивнои реализации интерфеисного метода в C# пе. њзи указмватв 
уровенв доступа (открмтми или закрмтми). Однако когда компилитор создает 
метаданнме длл метода, он назначает ему закрмтми уровенв доступа (private), 
что запрегцает лгобому коду исполвзоватв зкземплпр класса простмм вмзовом 
интерфеисного метода. Единственнми способ вмзватв интерфеиснми метод — об- 
ратитвсл через переменнуго зтого интерфеисного типа. 

Обратите внимание на то, что EIMI -метод не может 6biTb виртуалмгмм, а значит, 
его пе. њзи переопределитв. Зто происходит потому, что EIMI -метод в деиствителв- 
ности не нвлнетсл частрло обвектнои модели типа; зто всего лишв средство свизм- 
вангш интерфеиса (набора вариантов поведенгш, или методов) с типом. Если такои 
подход кажетсл вам немного неуклгожим, значит, вм все поннли npaeujibno. Далее 
в зтои главе н опишу некоторме деиственнме причинм длл исполвзованин EIMI. 


Обоб|деннне интерфеисн 

Поддержка обобгценнмх интерфеисов в C# и CLR открмвает перед разработчиками 
много интереснмх возможностеи. В зтом разделе рассказмваетсн о преимугцествах 
обобгценнмх интерфеисов. 

Во-первмх, обобгценнме интерфеисм обеспечивагот бсзопаспостп типов на ста- 
дии компилнции. Некоторме интерфеисм (такие, как необобгценнми IComparable) 
определигот методм, которме принимагот или возврагцагот параметрм типа Ob ј ect. 
При вмзове в коде методов таких интерфеисов можно передатв ссмлку на зкземплнр 
лгобого типа, однако обмчно зто нежелателвно. Приведем пример: 

private void SomeMethodl( ) { 

Int32 х = 1, у = 2; 

IComparable c = х; 

продолжение & 
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// CompareTo ожидает Object, 

// но вполне допустимо передатн переменнук) у типа Int32 
с.СотрагеТо(у); // Вк 1 полннетсл упаковка 

// CompareTo ожидает Object, 

// при передаче "2" (тип String) компиллцин вмполнлетсл HopManbHOj 
// но во времн вћтолненил генерируетсв искличение ArgumentException 
c.CompareTo("2"); 

} 

Лсно, что желателћно обеспечитБ более строгии контролБ типов в интерфеис- 
номметоде, позтому в I CI. hk. iiotcii обобгценнвшинтерфеис IComparable<T>. Вот 
нован версин кода, измененнаи с учетом исполвзовании обобгценного интерфеиса: 

private void SomeMethod2( ) { 

Int32 х = 1, у = 2; 

IComparable<Int32> c = х; 

// CompareTo ожидает Object, 

// но вполне допустимо передатн переменнук) у типа Int32 
с.СотрагеТо(у); // В|> 1 полнпетсл упаковка 

// CompareTo ожидает Int32, 

// передача "2" (тип String) приводит к ошибке компиллции 
// с сообшением о невозможности привести тип String к Int32 
c.CompareTo("2"); // Ошибка 

} 

Второе преимугцество обобгценнБ 1 х интерфеисов заклгочаетси в том, что при 
работе со значимвши типами требуетси менвше операции упаковки. Заметвте: 
в SomeMethodl необобшеннвш метод CompareTo интерфеиса IComparable ожидает 
переменнуго типа Object; передача переменнои у (значимнш тип Int32) приводит 
к упаковке значенин у. В SomeMethod2 метод CompareTo обобшенного интерфеиса 
IComparable<T> ожидает Int32; передача у ввшолниетсн по значениго, позтому 
упаковка не требуетсн. 

ПРИМЕЧАНИЕ 

В FCL определени необобиденнБ 1 е и обобиденнБ 1 е версии интерфеисов IComparable, 
ICollection, IList, I Dictionary и некоторнх других. Если Bbi определлете тип и хотите 
реализоватБ лкзбои из зтих интерфеисов, обБнно лучше внбиратБ обобиденнБ 1 е 
версии. НеобобиденнБ 1 е версии оставленБ! в FCLflns обратнои совместимости с ко- 
дом, написанннм до того, как в .NET Framevvork полвиласБ поддержка обобидении. 
Необобиденнме версии также предоставллкзт полБЗОвателпм механизм работм 
с даннмми более универсалБнмм, но и менее безопасним образом. 

НекоторБ 1 е обобиденнне интерфеиси 1 происходлт от необобиденннх версии, так что 
в классе приходитсл реализовБ 1 ватв как обобиденнукз, так и необобиденнукз версии. 
Например, обобиденнми интерфеис IEnumerable<T> наследует от необобиденного 
интерфеиса lEnumerable. Так что если кпасс реализует IEnumerable<T>, он должен 
также реализовати lEnumerable. 
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Иногда, при необходимости интеграции с другим кодом, приходитсн реализовмваљ 
необоб 1 деннв 1 и интерфеис просто потому, что необобиденнои версии не суидествует. 
В зтом случае, если лгобои из интерфеиснмх методов принимает или возвраидает 
тип Object, терлетсл безопасности типов при компиллции, и значимв 1 е типм должнм 
упаковв 1 ватвсл. Можно в некоторои степени исправити зту ситуацикз, деиствул так, 
как описано далее в разделе «Совершенствование безопасности типов за счет лвнои 
реализации интерфеисннх методов*. 


ТретБе преимудцество обобпденнмх интерфеисов заклгочаетсл в том, что класс 
может реализоватБ один интерфеис многократно, просто исполБзул параметрБг 
различного типа. Следугогции пример показБшает, как зто бћшает удобно: 

using System; 

// Зтот класс реализует обобценнни интерфеис IComparable<T> дваждм 
public sealed class Number: IComparable<Int32>, IComparable<String> { 
private Int32 m_val = 5; 

// Зтот метод реализует метод CompareTo интерфеиса IComparable<Int32> 
public Int32 CompareTo(Int32 n) { 
return m_val.CompareTo(n); 

} 


// Зтот метод реализует метод CompareTo интерфеиса IComparable<String> 
public Int32 CompareTo(String s) { 

return m_val.CompareTo(Int32.Parse(s)); 

> 

} 

public static class Program { 
public static void Main() { 

Number n = new Number(); 

// Значение n сравниваетсл co значением 5 типа Int32 
IComparable<Int32> clnt32 = n; 

Int32 result = cInt32.CompareTo(5); 

// Значение n сравниваетсл co значением "5" типа String 
IComparable<String> cString = n; 
result = cString.CompareTo("5"); 

} 

} 

Параметрвд интерфеиса обобгценного типа могут 6бдтб также помеченвд как 
контравариантБде или ковариантнБде, что позволнет более гибко исполБЗОватБ 
интерфеисБг. Подробнее о контравариантности и ковариантности рассказвшаетси 
в главе 12. 
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Обобиденич и ограниченил интерфеиса 

В предмдушем разделе бмли описанм преимушества обобпденнмх интерфеисов. 
В зтом разделе реч 1 > поидет о полћзе ограниченин параметров-типов таких интер- 
феисов. 

Первое преимугцество состоит в том, что параметр-тип можно ограничитБ не- 
сколбкими интерфеисами. В зтом случае тип передаваемого параметра должен 
реализоввшатБ все ограниченгш. Вот пример: 

public static class SomeType { 
private static void Test() { 

Int32 х = 5; 

Guid g = new Guid(); 

// Компиллцил атого вћвова M вуполнлетсл без проблем, 

// посколцку Int32 реализует и IComparable, и IConvertible 
М(х); 

// КОМПИЛЛЦИЛ ЗТ0Г0 BbBOBa М приводит к ошибке, посколцку 
// Guid реализует IComparable, но не реализует IConvertible 
M(g) ; 

} 

// Параметр Т типа М ограничиваетсл толцко теми типами, 

// которуе реализутт оба интерфеиса: IComparable И IConvertible 
private static Int32 M<T>(T t) where T : IComparable, IConvertible { 

} 

} 

ЗамечателБно! При определении параметров метода каждвш тип параметра 
указБшает, что передаваемБш аргумент должен иметБ заданнБП! тип или 6б1тб про- 
ИЗВОДНБ 1 М от него. Если типом параметра ивлиетсл интерфеис, аргумент может 
относитбсн к лгобому типу класса, реализугогцему заданнБги интерфеис. Исполб- 
зование несколБКих ограничении интерфеиса позволнет методу указвшатБ, что 
передаваемБш аргумент должен реализовБгватБ несколБКО интерфеисов. 

На самом деле, ограничивап Т классом и двумл интерфеисами, мбг говорим, что 
типом передаваемого аргумента должен 6бгтб указаннБш базовБги класс (или про- 
изводнбш от него), а также что он должен реализовБгватБ оба интерфеиса. Такаи 
гибкостБ позволнет методу диктоватв условгш вБгзБгвагогцему коду, а при невБгпол- 
ненгш установленнБгх ограничении возникагот ошибки компилнцгш. 

Второе преимугцество ограниченгш интерфеиса — избавление от упаковки при 
передаче зкземплиров значимвгх типов. В предвгдугцем фрагменте кода методу М 
передавалсн аргумент х (зкземплир типа Int32, то еств значимого типа). При пере- 
даче хвМ упаковканевБшолннласБ. ЕсликодметодаМвкгзовет t . CompareTo (...), 
то упаковка пргг ввгзове также не будет вбшолннтбсн (упаковка может вбшолннтбсн 
длн аргументов, передаваемвгх CompareTo). 
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В то же времл если М обЂнвллетсл следуклцим образом, то дли передачи х в М 
придетсл вђшолннтђ упаковку: 

private static Int32 M(IComparable t) { 

} 

Длн ограничении интерфеисов компилитор C# генерирует определеннме IL- 
инструкции, которме вмзмвагот интерфеиснми метод длл значимого типа напрлмуго, 
без упаковки. Кроме исполЂЗОванин ограничении интерфеиса нет другого способа 
заставитЂ компиллтор C# генерироватБ такие IL -инструкции; следователБно, во 
всех других случалх вмзов интерфеисного метода длн значимого типа всегда при- 
водит к упаковке. 


Реализацил несколБких интерфеисов 
с одинаковнми сигнатурами 
и именами методов 


Иногда нужно определитБ тип, реализугогции несколнко интерфеисов с методами, 
у которвгх совпадагот имена и сигнатурБЦ Допустим, два интерфеиса определенБ 1 
следугогцим образом: 

public interface IWindow { 

Object GetMenu(); 

} 

public interface IRestaurant { 

Object GetMenu(); 

} 

Требуетсл определитБ тип, реализугогции оба зтих интерфеиса. В зтом случае 
нужно реализоватБ членБ1 типа путем нвнои реализации методов: 

// Зтот тип пвлпетсл производнмм от System.Object 

// и реализует интерфеисм IWindow и IRestaurant 

public sealed class MarioPizzeria : IWindow, IRestaurant { 

// Реализацил метода GetMenu интерфеиса IWindow 
Object IWindow.GetMenu() { ... } 

// Реализацил метода GetMenu интерфеиса IRestaurant 
Object IRestaurant.GetMenu() { ... } 

// Метод GetMenu (необвзателцнти) , 

// не имегации отношенил к интерфеису 
public Object GetMenu() { ... } 

} 
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Так как зтот тип должен реализовмватћ несколБКО различнБ1х методов GetMenu, 
нужно сообтцитв компилитору С#, какои из методов GetMenu реализацшо дли кон- 
кретного интерфеиса. 

Код, в котором исполБзуетсл обвект MarioPizzenia, должен вбшолнитб при- 
ведение типа к определенному интерфеису длл ввиова нужного метода: 

MarioPizzeria mp = new MarioPizzeria(); 

// Зта строка вивмвает открмтми метод GetMenu класса MarioPizzeria 
mp.GetMenu(); 

// Зти строки Bbi3biBaK)T метод IWindow.GetMenu 
IWindow window = mp; 
window.GetMenu(); 

// Зти строки Bbi3biBaK)T метод IRestaurant.GetMenu 
IRestaurant restaurant = mp; 
restaurant.GetMenu(); 


Совершенствование безопасности 
типов за счет чвнои реализации 
интерфеиснБ1х методов 

Интерфеисв 1 оченБ удобнБц так как они определигот стандартнкш механизм взаи- 
модеиствии между типами. Ранее н говорил об обобгценнБ 1 х интерфеисах и о том, 
как они повБинагот безопасностБ типов при компилнции и позволнгот избавитвсн от 
упаковки. К сожалениго, иногда приходитсн реализоввшатБ необобгценнБге интер- 
феисБц посколБку обобгценнои версии попросту не сугцествует. Если какои-либо из 
интерфеиснБ 1 х методов принимает параметрБ 1 типа System .Ob ject или возврагцает 
значение типа System.Object, безопасноств типов при компилнции нарушаетсн 
и ББшолннетсн упаковка. В зтом разделе л показвшаго, как за счет ивнои реализации 
интерфеиснБ 1 х методов (EIMI) можно несколвко улучшитк ситуациго. 

Вот оченБ часто исполБзуемБш интерфеис IComparable: 

public interface IComparable { 

Int32 CompareTo(Object other); 

} 

B зтом интерфеисе определлетсл единственнБ 1 и метод, которБш принимает 
параметр типа System.Object. Если н определго собственннш тип, реализугогции 
зтот интерфеис, определение типа будет вБшллдетБ примерно так: 

internal struct SomeValueType : IComparable { 
private Int32 m_x; 

public SomeValueType(Int32 х) { m_x = х; } 
public Int32 CompareTo(Object other) { 
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return(m_x _ ( (SomeValueType) other).m_x); 

} 

} 


Исполћзун SomeValueType, н могу написатБ следуккции код: 

public static void Main() { 

SomeValueType v = new SomeValueType(0); 

Object o = new Object(); 

Int32 n = v.CompareTo(v); // НежелателБнаа упаковка 
n = v.CompareTo(o); // Исклтчение InvalidCastException 

} 

Зтот код нелБЗп назватБ идеалБНБш по двум причинам: 

□ нежелателћнан упаковка — когда переменнан v передаетсн в качестве аргумента 
методу CompareTo, она должна упаковБшатвси, посколБку CompareTo ожидает 
параметр типа Object; 

□ отсутствие безопасности типов — компилнции кода вБшолннетсл без проблем, 
но когда метод CompareTo тлтаетсн привести other к типу SomeValueType, воз- 
никает исклгочение InvalidCastException. 

Оба недостатка можно исправитв средствами EIMI. Вот модифицированнан 
версии типа SomeValueType, в которои имеет место ивнан реализацип интерфеис- 
нб 1 х методов: 

internal struct SomeValueType : IComparable { 
private Int32 m_x; 

public SomeValueType(Int32 х) { m_x = х; } 

public Int32 CompareTo(SomeValueType other) { 
return(m_x _ other.m_x); 

} 

// ПРИМЕЧАНИЕ: в следукицеи строке не исполвзуетсл public/private 
Int32 IComparable.CompareTo(Object other) { 
return CompareTo((SomeValueType) other); 

} 

} 

Обратите внимание на некоторвге измененгш в новои версии. Во-первБ 1 Х, здесБ 
два метода CompareTo. Перввш болБше не принимает параметр типа Object, а при- 
нимает параметр типа SomeValueType. Посколнку параметр изменилсн, код, вбшол- 
нлкнции приведение other к типу SomeValueType, стал ненужнвш и 6 бш удален. 
Во-вторБ 1 Х, изменение первого метода CompareTo длл обеспеченгш безопасности 
типов приводит к тому, что SomeValueType болвше не придерживаетсл контракта, 
обусловленного реализациеи интерфеиса IComparable. Позтому в SomeValueType 
нужно реализоватв метод CompareTo, удовлетворнклции контракту IComparable. 
Зтим занимаетсл второи метод CompareTo, которвп! исполвзует механизм ивнои 
реализации интерфеиснБ1х методов. 
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Зти два изменешш обеспечили безопасностБ типов при компилнции и избавили 
от упаковки: 

public static void Main() { 

SomeValueType v = new SomeValueType(0); 

Object o = new Object(); 

Int32 n = v.CompareTo(v); // Без упаковки 
n = v.CompareTo(o); // Ошибка компилпции 

} 

Однако если определитБ переменнуго интерфеисного типа, то mhi потернем без- 
опасностБ типов при компилнции и опнтб вернемсл к упаковке: 

public static void Main() { 

SomeValueType v = new SomeValueType(0); 

IComparable c = v; // Упаковка! 

Object o = new Object(); 

Int32 n = c.CompareTo(v); // Нежелателцнал упаковка 
n = c.CompareTo(o); // Исклшчение InvalidCastException 

} 


Как уже отмечалосв, при приведении зкземплирного типа к интерфеисному 
среда CLR должна упаковвшатв зкземплнр значимого типа. Позтому в приведенном 
методе Main вбшолннготси две упаковки. 

К EIMI часто прибегагот при реализации таких интерфеисов, как IConventible, 
ICollection, IList и IDictionary. Зто позволиет обеспечитв в интерфеиснБ 1 х методах 
безопасностБ типов при компилиции и избавитвси от упаковки значимБ1х типов. 


Опасности лвнои реализации 
интерфеиснБ1х методов 

Оченв важно пониматв некоторБ1е особенности EIMI, из-за которБ1х следует избе- 
гатБ пвнои реализации интерфеиснБ1х методов везде, где зто возможно. К счаствго, 
в некоторв1х случанх вместо EIMI можно обоитисв обобгценнвши интерфеисами. 
Но все равно остаготсл ситуации, когда без EIMI не обоитисв (например, при ре- 
ализации двух интерфеиснБ 1 х методов с одинаковвши именами и сигнатурами). 
С нвнои реализациеи интерфеиснБ1х методов свнзанБ1 некоторБге серБезнБге про- 
блемБ 1 (далее н расскажу о них подробнее): 

□ отсутствие документации, обБнсннгогцеи, как именно тип реализует EIMI -метод, 
а также отсутствие IntelliSense -поддержки в Microsoft Visual Studio; 

□ при приведении к интерфеисному типу зкземплирБ 1 значимого типа упаковБ 1 - 
ваготсл; 

□ EIMI нелБЗи вБИватБ из производного типа. 
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В описанинх методов типа в справочнои документации .NET Framework можно 
наити сведенин о нвнои реализации методов интерфеисов, но справка по конкрет- 
нмм типам отсутствует — доступна толбко обндаи информации об интерфеиснмх 
методах. Например, о типе Int32 говоритсн, что он реализует все методм интерфеиса 
IConventible. И зто хорошо, потому что разработчик знает, что такие методм су- 
гцествугот; с другои сторонм, зта информацин может создатБ проблемм, потому что 
вмзватБ метод интерфеиса IConventible длн Int32 напрнмуго нелћзн. Например, 
следугогции метод не скомпилируетсл. 

public static void Main() { 

Int32 х = 5; 

Single s = x.ToSingle(null); // Попитка вмзватв метод 

// интерфеиса IConvertible 

} 

При компилнции зтого метода компилитор C# вернет следугогцуго ошибку 
(ошибка CSOl 17: int не содержит определенгш длн ToSingle): 

error CS0117: 'int’ does not contain a definition for 'ToSingle’ 

Зто сообгцение об ошибке лишб запутмвает разработчика; в нем утверждаетсл, 
что в типе Int32 метод ToSingle не определен, хотл на самом деле зто неправда. 
Чтобм вмзватћ метод ToSingle типа Int32, сначала следует привести его к типу 

IConventible: 

public static void Main() { 

Int32 х = 5; 

Single s = ((IConvertible) х) .ToSingle(null); 

} 

Требование приведенгш типа далеко не очевидно, многие разработчики не могут 
самостолтелБно до зтого додуматБСн. Но на зтом проблемм не заканчиваготсн — при 
приведении значимого типа Int32 к интерфеисному типу IConventible значимми 
тип упаковмваетсл, что приводит к лишним затратам памнти и снижениго произ- 
водителБности. Зто вторан серБезнаи проблема. 

ТретБн и, наверное, самаи серБезнан проблема с EIMI состоит в том, что нвнан 
реализацин интерфеисного метода не может вБШБшатБСн из производного класса. 
Вот пример: 

internal class Base : IComparable { 

// Лвнап реализацил интерфеисного метода (EIMI) 

Int32 IComparable.CompareTo(Object о) { 

Console.WriteLine("Base's CompareTo"); 
return 0; 

} 

} 


internal sealed class Derived : Base, IComparable { 

// Откритми методЈ также нвллклциисп реализациеи интерфеиса 
public Int32 CompareTo(Object о) { 


продолжение & 
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Console.WriteLine("Derived’s CompareTo"); 

// Зта попмтка втзватв EIMI базового класса приводит к ошибке: 

// "error CS0117: 'Base’ does not contain a definition for ’CompareTo'" 
base.CompareTo(o); 
return 0 ; 

} 

} 

B методе CompareTo типа Derived н попмталси вћвватћ base .CompareTo, но зто 
привело к ошибке компилнтора С#. Проблема заклгочаетсл в том, что в классе Base 
нет открмтого или загцишенного метода CompcareTo, которми он мог бм вмзватБ. 
Естб метод CompareTo, которБит можно вБгзватБ толбко через переменнуго типа 
IComparable. Л мог 6 ki изменитБ метод CompareTo класса Derived следуклцим об- 
разом: 

// Открштши метод, которши также лвллетсл реализациеи интерфеиса 
public Int32 CompareTo(Object о) { 

Console.WriteLine("Derived's CompareTo"); 

// Зта попштка вшзова EIMI базового класса приводит 
// к бесконечнои рекурсии 
IComparable с = this; 
c.CompareTo(o); 

return 0 ; 

} 

В зтои версии н привожу this к типу переменнои с (типу IComparable), а за- 
тем исполвзуго с длл вБИОва CompareTo. Однако открвмБш метод CompareTo класса 
Derived нвлнетсл реализациеи метода CompareTo интерфеиса IComparable класса 
Derived, позтому возникает бесконечнан рекурсин. Ситуациго можно исправитв, 
о6бнвив класс Derived без интерфеиса IComparable: 
internal sealed class Derived : Base /*, IComparable */ { ... } 

Теперв предБвдугции метод CompareTo вБ130вет метод CompareTo класса Base. 
Однако не всегда можно просто удалитв интерфеис из типа, посколБку производ- 
нбпт тип должен реализовБшатБ интерфеиснБп! метод. Лучшии способ исправитБ 
ситуациго — в дополнение к нвно реализованному интерфеисному методу создатв 
в базовом классе виртуалБНБп! метод, которнш будет реализовБшатБСн нвно. Затем 
в классе Derived можно переопределитв виртуалБНБН! метод. Вот как правилБно 
определнтБ классБ 1 Base и Derived: 
internal class Base : IComparable { 

// Ввнал реализацил интерфеисного метода (EIMI) 

Int32 IComparable.CompareTo(Object o) { 

Console.WriteLine("Base’s IComparable CompareTo"); 
return CompareTo(o); // Теперц здесц вћвшваетсн виртуалцнши метод 
} 
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// Виртуалвнми метод длд производнмх классов 
// (зтот метод может имети лтбое имн) 
public virtual Int32 CompareTo(Object o) { 

Console.WriteLine("Base's virtual CompareTo"); 
return 0; 

} 

} 

internal sealed class Derived : Base, IComparable { 

// Открнтми метод^ которми также лвллетсл реализациеи интерфеиса 
public override Int32 CompareTo(Object o) { 

Console.WriteLine("Derived’s CompareTo"); 

// Tenepb можно визвати виртуалинни метод класса Base 
return base.CompareTo(o); 

} 


Заметћте: л определил виртуалБНБш метод как открв 1 тми, но в некотормх 
случалх лучше сделатБ его загцшценнмм. Зто вполне возможно, хоти и потребует 
неболБших изменении. 

Как видите, к нвнои реализации интерфеиснмх методов нужно прибегатБ с осто- 
рожностБШ. Когда разработчики впервме узнали о EIMI, многие посчитали зто 
отличнои новостбк) и стали пмтатБСн вбшолннтб нвнук) реализацшо интерфеиснБ1х 
методов везде, где толбко можно. Не попадаитесБ на зту удочку! Нвнаи реализацгш 
интерфеиснБ1х методов полезна в лишб некоторБ1х случаих, но ее следует избегатБ 
везде, где можно обоитисБ другими средствами. 


Дилемма разработчика: базовми 
класс или интерфеис? 

Мени часто спрашивагот, что лучше вБ 1 биратБ длн проектировании типа — базовБш 
тип или интерфеис? Ответ не всегда очевиден. Вот несколБКО правил, которБ 1 е 
могут помочб вам сделатБ Bbi6op. 

□ Свлзб потомка с предком. Лгобои тип может наследоватБ толбко одну реа- 
лизациго. Если производнБш тип не может ограничиватБСи отношением типа 
<<ивлнетсл частнБш случаем» с базовБгм типом, нужно применитБ интерфеис, 
а не базовБги тип. Интерфеис подразумевает отношение «поддерживает функ- 
ционалБностБ». Например, тип может преобразовБ1ватБ зкземплирБ1 самого 
себл в другои тип (IConvertible), может создатБ набор зкземплнров самого 
себи (ISerializable) и т. д. ЗаметБте, что значимБге типбг должнбг наследоватБ 
от типа System . ValueType и позтому не могут наследоватБ от произволБного 
базового класса. В зтом случае нужно определлтБ интерфеис. 
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□ Простота исполћзованиа. Разработчику проше определитБ новбш тип, произ- 
воднб1и от базового, чем создатв интерфеис. БазовБ1и тип может предоставлитБ 
массу функции, и в производном типе потребуетсн внести лишб незначителБНБге 
измененил, что 6 б 1 изменитБ его поведение. При создании интерфеиса в новом 
типе придетсл реализоввшатБ все членвг 

□ Четкан реализацин. Как 6ki хорошо ни 6бш документирован контракт, врлд 
ли будет реализован абсолтотно корректно. По сути, проблемБ 1 СОМ свизанБ 1 
именно с зтим — вот почему некоторвге СОМ-о 6 бсктб 1 нормалБно работагот 
толбко с Microsoft Word или Microsoft Internet Explorer. БазовБН! тип с хорошеи 
реализациеи ochobhhix функции — прекраснан отправнан точка, вам останетсн 
изменитв лишб отделБНБге части. 

□ Управление версинми. Когда bbi добавлнете метод к базовому типу, производ- 
нбш тип наследует стандартнуго реализациго зтого метода без вснких затрат. 
ПолБЗОвателБСКии исходнбш код даже не нужно перекомпилироватБ. Добавление 
нового члена к интерфеису требует измененгш полвзователБСКого исходного 
кода и его перекомпилнции. 

В FCL классБг, свнзаннБге с потоками данннгх, построенБг по принципу насле- 
довангш реализации. System . 10. Stream — зто абстрактнвпт базовппт класс, предо- 
ставлнгогции множество методов, в том числе Read и Write. Другие классБ 1 (Sy stem . 
10. FileStream,System.IO.MemoryStream и System.Net .Sockets.NetworkStream) 
нвлиготсл производнБши от Stream. B Microsoft вБ 1 брали такои вид отношении 
между зтими тремн классами и Stream по тои причине, что так прогце реализовБшатв 
конкретнБге классБт Так, производнБге классБ1 должнб1 самостонтелБно реализоватБ 
толбко операции синхронного ввода-вБшода, а способностБ вбшолнчтб асинхроннБге 
операции наследуетсл от базового класса Stream. 

Возможно, BBi6op наследованин реализации длл классов, работагогцих с пото- 
ками, не совсем очевиден: ведв базовБги класс Stream на самом деле предоставллет 
лишб ограниченнуго готовуго функционалвностБ. Однако если взглннутБ на классБг 
злементов управленгш Windows Forms, где Button, CheckBox, ListBox и все прочие 
алементБ 1 управленин порождаготсн от System . Windows . Forms . Control, легко пред- 
ставитв обвем кода, реализованного в Control; весв зтот код просто наследуетсл 
классами злементов управленгш, позволни им правилвно функционироватБ. 

Что касаетсл коллекцип (collections), то их специалистБг Microsoft реализовали 
в FCL паоспове nmep())eiicoi:. В npocTpaHCTBerrMeHSystem.Collections.Generic 
определено несколвко интерфеисов длн работвг с коллекцгшми: IEnumerable<T>, 
ICollection<T>, IList<T> и IDictionary<TKey, TValue>. Кроме того, Microsoft 
предлагает несколнко конкретнкгх классов (таких, как List<T>, Dictionary<TKey, 
TValue>, Queue<T>, Stack<T> и пр.), которвге реализугот комбинацгш зтих интер- 
феисов. Такои подход обБнсниетсл тем, что реализацгш всех классов-коллекцгш 
сугцественно различаетсл. Иначе говорн, у List<T>, Dictionary<TKey, TValue> 
и Queue<T > наидетси не так много обгцего кода. 
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И все же операции, предлагаемме всеми зтими классами, вполне согласованм. 
Например, все они поддерживагот подмножество злементов с возможностбго пере- 
бора, все они позволигот добавлптБ и удаллтБ злементБг Если естБ ссБшка на обв- 
ект, тип которого реализует интерфеис IList<T >, можно написатк код, способнкпт 
добавлнтБ, удаллтБ и искатБ злементБц не знан конкретннпт тип коллекции. Зто 
оченБ могцнбпт механизм. 

Наконец, нужно сказатн, что на самом деле можно определитБ интерфеис и соз- 
датБ базовБш класс, которкги реализует интерфеис. Например, в FCL определен 
интерфеис IComparer<T >, и лгобои тип может реализоватв зтот интерфеис. Кроме 
того, FCL предоставллет абстрактнвги базовБш класс Comparer<T>, которБги реа- 
лизует зтот интерфеис (абстрактно) и предлагает реализациго по умолчаниго длл 
необобшенного метода Compare интерфеиса IComparer. Применение обеихвозмож- 
ностеи дает болвшуго гибкостБ, посколБку разработчики теперк могут вггбратБ из 
двух вариантов наиболее предпочтителвнБш. 
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Глава 14. Символм, строки 
и обработка текста 


Зта глава nocnaiiuTia приемам обработки отделБнмх символов, а также целмх строк 
в Microsoft .NET Framework. Вначале рассматриваготси структура System.Char 
и способм работм с символами. Потом мм переидем к весБма полезному классу 
System . String, предназначенному дли работБ 1 с неизменнемБши строками (такуго 
строку можно создатБ, но не изменитБ). Затем рассказБ1ваетси о динамическом 
построении строк с помовдбго класса System.Text.StringBuilder. РазобравшисБ 
с основами работБ1 со строками, mki обсудим вопросБ1 форматированин обвектов 
в строки и зффективного сохраненгш и передачи строк в различнБ 1 х кодировках. 
В конце главБ 1 рассказБшаетси о классе System.Security.SecureString, которБпг 
может исполБЗОватБСн длл завдитБ1 конфиденциалБНБ1х строк даннБ1х, таких как 
пароли и номера кредитшлх карт. 


СиМВО /lbl 

Символб1 в .NET Framework всегда представленБ1 16 -разрнднБши кодами стандарта 
КЗникод, что облегчает разработку многонзбшовбгх приложении. Символ пред- 
ставлнетси зкземплиром структурБ1 System . Char (значимвш тип). Тип System . Char 
доволбно прост, у него лишб два otkpbitbix неизменнемБ1х полн: константа MinValue, 
определеннан как ' \ 0 ", и константа MaxValue, определеннан как ' \uffff '. 

Длн зкземплира Char можно вБ 13 БшатБ статическии метод GetUnicodeCategory, 
которБнг возвравдает значение перечислимого типа System . Globalization . 
UnicodeCategory, показвшаговдее категориго символа: управлнговдии символ, символ 
валготБц буква в нижнем или верхнем регистре, знак препинашш, математическии 
символ и т. д. (в соответствии со стандартом КЗникод). 

Длн облегченгш работБ1 с типом Char имеетси несколнко статических методов, 
например: IsDigit,IsLetter,IsWhiteSpace,IsUpper, IsLower, IsPunctuation,Is- 
LetterOrDigit, IsControl, IsNumber, IsSeparator, IsSurrogate,IsLowSurrogate, 
IsHighSurrogate и IsSymbol. Болбшинство зтих методов обравдаетси 
к GetUnicodeCategory и возвравдает true или false. В параметрах зтих методов 
передаетсл либо одиночнбпг символ, либо зкземшшр String и индекс символа 
в строке. 

Кроме того, статические методБ1 ToLowerInvariant и ToUpperlnvariant по- 
зволнгот преобразоватв символ в его зквивалент в нижнем или верхнем регистре 
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без учета регионалћнмх стандартов. Длн преобразованин символа с учетом регио- 
налБнмх стандартов (culture), относигцихсн к вмзмвагогцему потоку (зти сведенгш 
методм получагот, запрашиваи статическое своиство CurrentCulture типа System . 
Globalization . Culturelnfo), служат методм ToLower и ToUpper. Чтобм задатг> 
конкретнБпг набор регионалБНБгх стандартов, передаите зтим методам зкземплнр 
класса Culturelnfo. Даннвге о регионалБНБГх стандартах необходимБг методам 
ToLower и ToUpper, посколбку от них зависит резулвтат операции измененгш ре- 
гистра буквБт Например, в турецком изшсе символ U+0069 (латинскаи строчнаи 
буква i) при переводе в верхнии регистр становитсл символом U+0130 (латинскан 
прописнаи буква I с надстрочнои точкои), тогда как в других лзвгках — зто символ 
U+0049 (латинскан прописнан буква I). 

Помимо перечисленнвгх статических методов, у типа Char еств также несколк- 
ко собственнБгх зкземплнрнБгх методов. Метод Equals возврагцает true, если два 
зкземплнра Char представлнгот один и тот же 16-разриднвш символ КОникода. Ме- 
тод CompareTo (определеннвпг в интерфеисах IComparable и IComparable<Char>) 
сравнивает два кодовбгх значенгш без учета регионалБНБгх стандартов. Метод Con- 
vertFromUtf 32 создает строку, состонгцуго из одного или двух символов UTF-16, 
длл одного символа UTF-32. Метод ConvertToUtf32 создает символ UTF-32 длл 
суррогатнои парвг или строки. Метод ToString возврагцает строку, состоигцуго из 
одного символа, тогда как Parse и TryParse получагот односимволБнуго строку 
String и возврагцагот соответствугогцуго кодовуго позициго UTF-16. 

Наконец, метод GetNumericValue возврагцает числовои зквивалент символа. 
Зто можно продемонстрироватБ на следугогцем примере: 

using System; 


public static class Program { 
public static void Main() { 

Double d; 

d = Char.GetNumericValue(" \u0033 '); 
Console. WriteLine(d. ToStringO); 


// '\u0033' - зто "цифра 3" 
// Параметр '3' 

// даст тот же резулцтат 
// Вмводитсд "3" 


// '\u00bc' - зто "простад дробц одна четвертал ('1/4')" 
d = Char.GetNumericValue( ' \u00bc '); 

Console.WriteLine(d . ToString( )); // Виводитсв "0.25" 

// 'A' - зто "Латинскад прописнан буква А" 
d = Char.GetNumericValue( 'А'); 

Console.WriteLine(d . ToString( )); // Виводитсн "-1" 

} 

} 

A теперн представлго в поридке предпочтенгш три способа преобразовангш раз- 
личнБгх ЧИСЛОВБ 1 Х типов в окзсм 1 1 . ; ш|) i,i типа Char, и наоборот. 

□ Приведение типа. Самвш зффективнБпг способ, так как компилнтор генерирует 
IL -командБг преобразовангш без вбгзовов каких-либо методов. Длн преобразо- 
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вании типа Char в числовое значение, такое как Int32, приведение подходит 
лучше всего. Кроме того, в некотормх лзмках (например, в С#) допускаетсл 
указмватБ, какои код должен исполћзоватБСи при ВБШоленнии преобразовангш: 
провернемБги или непроверпемБпт (см. главу 5 ). 

□ Исполћзование типа Convert. У типа System . Convert еств несколБКО ста- 
тических методов, корректно преобразугогцих Char в числовои тип и обрат- 
но. Все зти методвг вбшолнпгот преобразование как провериемуго операциго, 
чтобвг в случае потери даннвгх при преобразовании возникало исклгочение 

OverflowException. 

□ ИсполБзование интерфеиса IConvertible. В типе Char и во всех числовбгх 
типах библиотеки .NET Framework Class Library (FCL) реализован интерфеис 
IConvertible, в котором определенБГтакие методБц как ToUIntie и ToChar. Зтот 
способ наименее зффективен, так как вбгзов интерфеиснвгх методов длл число- 
вб 1 х типов приводит к упаковке зкземплнра: Char и все числоввге типбг нвлнготсн 
значимБши типами. МетодБг IConvertible генериругот исклгочение System. 
InvalidCastException, если преобразование невозможно (например, преобразо- 
вание типа Char в Boolean) или грозит потереи даннвгх. Во многих типах (в том 
числе Char и числовбгх типах FCL) исполБзуготсл EIMI -реализации методов 
IConvertible (см. главу 13), а значит, перед вбгзовом какого-либо метода зтого 
интерфеиса нужно вбшолнитб пвное приведение зкземшшра к IConvertible. 
Все методвг IConvertible за исклгочением GetTypeCode принимагот сскшку 
на обвект, реализугогции интерфеис IFormatProvider. Зтот параметр полезен, 
когда по какои-либо причине при преобразовании требуетсл учитвгватв регио- 
налБНБге стандартБг. В болБшинстве операции преобразованип в зтом параметре 
передаетсл null, потому что он все равно игнорируетсл. 

Применение всех трех способов продемонстрировано в следугогцем примере: 

using System; 

public static class Program { 
public static void Main() { 

Char c; 

Int32 n; 

// Преобразование "число - символ" посредством приведенив типов C# 
с = (Char) 65; 

Console.WriteLine(c); // Виводитсл "А" 
n = (Int32) с; 

Console.WriteLine(n); // Виводитсл "65" 

с = unchecked((Char) (65536 + 65)); 

Console.WriteLine(c); // Виводитсв "А" 


// Преобразование "число - символ" с помошбк) типа Convert 
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с = Convert.ToChar(65); 

Console.WriteLine(c); // Вв 1 водитсп "A" 

n = Convert.ToInt32(c); 

Console.WriteLine(n); // Вшодитсп "65" 

// Демонстрацип проверки диапазона длл Convert 
try { 

с = Convert . ToChar(70000) ; // Слишком много длл 16 разрлдов 
Console.WriteLine(c); // Зтот вмзов вшполнлтвсн НЕ будет 

} 

catch (OverflowException) { 

Console . WriteLine("Can ' t convert 70000 to a Char."); 

} 

// Преобразование "число - символ" c noMombio интерфеиса IConvertible 
c = ((IConvertible) 65).ToChar(null); 

Console.WriteLine(c); // Вшводитсл "A" 

n = ((IConvertible) c).ToInt32(null); 

Console.WriteLine(n); // Вшводитсл "65" 

} 


Тип System.String 

Один из самнх полезнмх типов, встречакнцихси в лкзбом приложении — System. 
String, — представлиет неизменпемми упорлдоченнми набор символов. Будучи 
прнммм потомком Object, он нвлнетси ссмлочнмм типом, по зтои причине стро- 
ки всегда размегцаготси в куче и никогда — в стеке потока. Тип String реализует 
также несколБКО интерфеисов (IComparable/IComparable<String>, ICloneable, 
IConvertible, IEnumerable/IEnumerable<Char> и IEquatable<String>). 

Создание строк 

Во многих цзмках (вклгочаи С#) String относитсл к примитивнмм типам, то естБ 
компилнтор разрешает вставлнтБ литералБНБге строки непосредственно в исходнбп! 
код. Компилитор помегцает зти литералкнБШ строки в метаданнБШ модулл, откуда 
они загружаготсл и исполБзуготсл во времл ввшолнешш. 

В C# оператор new не может исполБЗОватБСи длн создании обвектов String из 
литералвнБ1х строк: 

using System; 

public static class Program { 
public static void Main() { 

продолжение & 
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Stning s = new String("Hi there."); // Ошибка 
Console.WriteLine(s); 

} 


Вместо зтого исполћзуетси более простои синтаксис: 

using System; 

public static class Program { 
public static void Main() { 

String s = "Hi there."; 

Console.WriteLine(s); 

} 

} 


Резулћтат компиллции зтого кода можно посмотретћ с помогцбјо утилитБ1 
ILDasm.exe: 

.method public hidebysig static void Main() cil managed 

{ 

.entrypoint 

// Code size 13 (0xd) 

.maxstack 1 

.locals init (string V_0) 

IL_0000: ldstr "Hi there." 

IL_0005: stloc.0 
IL_0006: ldloc.0 

IL_0007: call void [mscorlib]System.Console::WriteLine(string) 

IL_00@c: ret 

} // end of method Program::Main 

За создание нового зкземплира обвекта отвечает IL -команда newobj. Однако 
здесв зтои командБ 1 нет. Вместо нее bhi видите специалБнук) IL -команду ldstn 
(загрузка строки), котораи создает обвект Stning на основе литералвнои строки, 
полученнои из метаданнБ 1 х. Отсгода следует, что обЂектБ 1 Stning в CLR создаготсн 
по специалвнои схеме. 

ИсполБзун небезопаснБп! код, можно создатк обвект Stning с помогцбго Chan* 
и SByte*. Длн зтого следует применитБ оператор new и вБИватБ один из конструк- 
торов типа Stning, получагогцих параметрв 1 Chan* и SByte*. Зти конструкторв 1 
создагот обвект Stning и заполннгот его строкои, состоигцеи из указанного массива 
зкземплнров Chan или баитов со знаком. У других конструкторов нет параметров- 
указателеи, их можно ввговатБ из лгобого нзБжа, создагогцего управлиемБ1и код. 

В C# имеетси специалБНБп! синтаксис длн вклгоченгш литералБнвгх строк в ис- 
ходнБП! код. Длл вставки специалвнвгх символов, таких как конец строки, возврат 
каретки, забои, в C# исполвзуготсл управлигогцие последователвности, знакомБге 
разработчикам на С/С++: 

// String содержит символш конца строки и перевода каретки 
String s = "Hi\r\nthere. "; 
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ЗадаватБ в коде последователвносљ символов конца строки и перевода каретки 
напрлмунз, как зто сделано в представленном примере, не рекомендуетсл. У типа 
System.Environment определено неизменпемое своиство NewLine, которое при вм- 
полнении приложенип в Windows возвраидает строку, состолш,у 10 из зтих символов. 
Однако своиство NewLine зависит от платформм и возвраидает ту строку, которал 
обеспечиваетсоздание разрмва строк на конкретнои платформе. Скажем, при пере- 
носе CLI в UNIX своиство NewLine должно возвраидатв строку, состолиду 10 толвко из 
символа «\n». Чтобм приведеннми код работал на лкдбои платформе, перепишите 
его следугоидим образом: 

String s = "Hi" + Environment . NewLine + "there."; 


Чтобм обЂединитћ несколЂКО строк в одну строку, исполЂзуите оператор + 
измка С#: 

// Конкатенацин трех литералннмх строк образует одну литералннун) строку 
String s = "Hi" + " " + "there."; 

ПосколЂку все строки в зтом коде литералмдме, компиллтор вмполннет их конка- 
тенацшо на зтапе компилнции, в резулкгате в метаданнмх модулн оказмваетсл лишђ 
строка "Hi there .". Конкатенации нелитералЂнмх строк с помотмо оператора + 
происходит на зтапе вмполненил. Длн конкатенации несколмсих строк на зтапе вм- 
полненин оператор + применнтЂ нежелателћно, так как он создает в куче несколЂКО 
строковмх обЂектов. Вместо него рекомендуетсн исполвзоватЂ тип System.Text. 
StringBuilder (о нем рассказано далее). 

И наконец, в C# еств особми вариант обЂнвленин строки, в которои все символм 
между кавмчками трактуготсн как частв строки. Зти специалЂнме обЂнвлендш — 
буквалтие строки (verbatim strings) — обмчно исполвзугот при задании пути 
к фаилу или каталогу и при работе с регулнрнмми вмраженинми. Следугогции 
пример показмвает, как о6ђпвитђ одну и ту же строку с исполЂЗОванием признака 
буквалвнмх строк (§) и без него: 

// Задание пути к приложеник) 

String file = "С: \\Windows\\System32\\Notepad .ехе"; 

// Задание пути к приложениго с nOMOuibro буквалБнои строки 
String file = @"С: \Windows\System32\Notepad .ехе"; 

Оба фрагмента кода дагот одинаковми резулкгат. Однако символ @ перед стро- 
Koii во втором случае сообгцает компилнтору, что перед ним буквалвнап строка 
и он должен рассматриватЂ символ обратнои Kocoii чертм (\) буквалвно, а не как 
префикс управлигогцеи последователвности, благодари чему путЂ в коде вмглндит 
более привмчно. 

Теперв, познакомившисЂ с формированием строк, рассмотрим операции, вм- 
полниемме над обЂектами типа String. 


362 Глава 14. Символн, строки и обработка текста 


Неизменлемме строки 

Самое важное, что нужно помнитб об обвекте Stning — то, что он неизменнем; то естБ 
созданнуго однаждБ1 строку нелкзи сделатБ длиннее или короче, в неи нелвзи из- 
менитБ ни одного символа. Неизменноств строк дает определеннБге преимугцества. 
Длл начала можно вбшолннтб операции над строками, не изменнн их: 

if (s.ToUpperInvariant().Substring(10j 21). EndsWith( "ЕХЕ" )) { 

} 

ЗдесБ ToUppenlnvaniant возврагцает новуго строку; символб 1 в строке s не 
изменнготсл. SubStning обрабатвшает строку, возврагценнуго ToUppenlnvaniant, 
и тоже возврагцает новуго строку, которал затем передаетсл методу EndsWith. 
В программном коде приложенин нет ссбшок на две временнвге строки, созданнвге 
ToUppenlnvaniant и SubStning, позтому заннтал ими памитв освободитсл при 
очереднои уборке мусора. Если ввшолннетсн много операции со строками, в куче 
создаетсл много обвектов Stning — зто заставлиет чагце прибегатв к помогци убор- 
гцика мусора, что отрицателБно сказБшаетси на производителБности приложенгш. 

Благодарн неизменности строк отпадает проблема синхронизации потоков при 
работе со строками. Кроме того, в CLR несколвко ссбшок Stning могут указкшатБ 
на один, а не на несколБКО разнкгх строковБгх обвектов, если строки идентичнБг. 
А значит, можно сократитБ количество строк в системе и уменвшитБ расход памн- 
ти — зто именно то, что непосредственно относитсн к интернированит строк (string 
interning), о котором речв поидет далБше. 

По соображенгшм производителБности тип Stning тесно интегрирован с CLR. 
В частности, CLR «знает» точное расположение полеи в зтом типе и обрагцаетси 
к ним напримуго. За повБштение производителБности и прнмои доступ приходитси 
платитБ неболБшуго цену: класс Stning нвлнетсл запечатаннвш. Иначе, имен возмож- 
ностб описатБ собственнБш ТИП, ПрОИЗВОДНБШ от Stning, можно 6 бшо 6б1 добавлнтБ 
свои полн, противоречагцие структуре Stning и нарушагогцие работу CLR. Кроме 
того, ваши деиствгш могли 6 bi нарушитв предположенгш CLR об обвекте Stning, 
которнге вБгтекагот из его неизменности. 


Сравнение строк 

Сравнение — пожалуи, наиболее часто ввшолннеман со строками операцгш. Естб две 
причинБг, по которнш приходитсл сравниватБ строки. Мбг сравниваем две строки 
дли вБшсненгш, равнБг ли они, и длл сортировки (прежде всего, длл представленгш 
их полБЗОвателго программБг). 

Длл проверки равенства строк и длл их сравненгш при сортировке н настонтелвно 
рекомендуго исполвзоватБ один из перечисленнБгх далее методов, реализованнвгх 
в классе Stning: 

Boolean Equals(String value, StringComparison comparisonType) 

static Boolean Equals(String a, String b, StringComparison comparisonType) 
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static Int32 Compare(String stnA, String stnB, 

StringComparison comparisonType) 
static Int32 Compare(string strA, string strB, 

Boolean ignoreCase, Culturelnfo culture) 
static Int32 Compare(String strA, String strB, 

Culturelnfo culture, CompareOptions options) 

static Int32 Compare(String strA, Int32 indexA, String strB, Int32 indexB, 

Int32 length, StringComparison comparisonType) 
static Int32 Compare(String strA, Int32 indexA, String strB, Int32 indexB, 

Int32 length, Culturelnfo culture, CompareOptions options) 
static Int32 Compare(String strA, Int32 indexA, String strB, Int32 indexB, 

Int32 length, Boolean ignoreCase, Culturelnfo culture) 

Boolean StartsWith(String value, StringComparison comparisonType) 

Boolean StartsWith(String value, 

Boolean ignoreCase, Culturelnfo culture) 

Boolean EndsWith(String value, StringComparison comparisonType) 

Boolean EndsWith(String value, Boolean ignoreCase, Culturelnfo culture) 

При сортировке всегда нужно учитмватБ регистр символов. Дело в том, что две 
строки, отличаклциесн липњ регистром символов, будут считатћси одинаковмми 
и позтому при каждои сортировке они могут упорлдочиватБСл в произволБном 
порндке, что может приводитБ полБЗОвателн в замешателвство. 

В аргументе comparisonType (он еств в болвшинстве перечислешплх методов) 
передаетсн одно из значении, определеннБ1х в перечислимом типе StringComparison, 
которБП! определен следуклцим образом: 

public enum StringComparison { 

CurrentCulture = 0, 

CurrentCulturelgnoreCase = 1, 

InvariantCulture = 2, 

InvariantCulturelgnoreCase = 3, 

Ordinal = 4, 

OrdinallgnoreCase = 5 

} 

Аргумент options лвллетсл одним из значении, определеннБ1х перечислимБш 
типом CompareOptions: 

[Flags] 

public enum CompareOptions { 

None = 0, 

IgnoreCase = 1, 

IgnoreNonSpace = 2, 

IgnoreSymbols = 4, 

IgnoreKanaType = 8, 

IgnoreWidth = 0x00000010, 

Ordinal = 0x40000000, 

OrdinallgnoreCase = 0x10000000, 

StringSort = 0x20000000 

} 
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Методм, работаклцие с аргументом CompareOptions, также подцерживагот авнуго 
передачу информации о измке и регионалБнмх стандартах. Если установлен флаг 
Ordinal или OrdinallgnoreCase, тогда методм Compare игнориругот определеннми 
нзмк и регионалБнме стандартм. 

Во многих программах строки исполБзуготси длл решенин внутренних задач: 
представленин имен путеи и фаилов, URL -адресов, параметров и разделов реестра, 
переменнмх окружентш, отраженгш, XML-TeroB, ХМЕ-атрибутов и т. п. Часто та- 
кие строки вообгце не вмводнтсл, а исполБзуготси толбко внутри программм. Дли 
сравненгш внутренних строк следует всегда исполБЗОватБ флаг StringComparison . 
Ordinal или StringComparison .OrdinallgnoreCase. Зто самми бмстрми способ 
сравненин, так как он игнорирует лингвистические особенности и регионалБнме 
стандартм. 

С другои сторонм, если требуетсн корректно сравнитБ строки с точки зренгш 
лингвистических особенностеи (обмчно перед вмводом их на зкран длл полћ- 
зователи), следует исполБЗОватБ флаг StringComparison . CurrentCulture или 
StringComparison.CurrentCulturelgnoreCase. 

ВНИМАНИЕ 

06bNHO следует избегаљ исполнзованил флагов StringComparison.lnvariantCulture 
и StringComparison.lnvariantCulturelgnoreCase. Хотл зти значенил и позволлкзт вн- 
полниљ лингвистически корректное сравнение, применение ихдпч сравненил строк 
в программе занимает болише времени, чем с флагом StringComparison.Ordinal 
или StringComparison.OrdinallgnoreCase. Кроме того, игнорирование регионалвнмх 
стандартов — совсем неудачни 1 и вмбор длч сортировки строк, которме планируетсл 
показмвати полвзователк). 


ВНИМАНИЕ 

Если Bbi хотите изменитБ регистр символов строки перед вмполнением простого 
сравненич, следует исполвзовати предоставлчемми String метод ToUpperlnvariant 
или ToLovverlnvariant. При нормализации строк настолтелино рекомендуетсл ис- 
полизоваљ метод ToUpperlnvariant, а не ToLovverlnvariant из-за того, что в Microsoft 
сравнение строк в верхнем регистре оптимизировано. На самом деле, в FCL перед 
не завислгцим от регистра сравнением строки нормализуктг путем приведенил их 
к верхнему регистру. 


Иногда длл лингвистически корректного сравненгш строк исполБзугот регио- 
налБнме стандартм, отличнме от регионалБнмх стандартов вмзмвагогцего потока. 
В таком случае можно задеиствоватБ перегруженнвге версии показаннБгх ранее 
методов StartsWith, EndsWith и Compare — все они принимагот аргументћг Boolean 
и Culturelnfo. 

А теперБ поговорим о лингвистически корректнБгх сравненинх. Длн представле- 
iniri napbr «изБгк-страна» (как опггсано в спецификации RLC 1766) в .NET Lramework 
исполБзуетсл тип System.Globalization.CultureInfo. В частности, en-US озна- 
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чает американскуго (США) версиго англииского нзмка, en-AU — австралиискуго 
версиго англииского измка, а de-DE германскуго версиго немецкого измка. В CLR 
у каждого потока естБ два своиства, относнгциесн к зтои паре и ссћшагогциесн на 
обвект Culturelnfo. 

□ CurrentUICulture служит длл полученин ресурсов, видимбгх конечному полб- 
зователго. Зто своиство наиболее полезно дли графического интерфеиса полб- 
зователи или приложении Web Forms, так как оно обозначает нзбгк, которкш 
следует вкгбратБ длл вБгвода злементов полвзователБСКого интерфеиса, таких 
как надписи и кнопки. По умолчаниго при создании потока зто своиство потока 
задаетсл \\'|||, 32 -фупктш(‘и GetUserDefaultUILanguage на основании обвекта 
Culturelnf о, которвпг указншает на нзбж текугцеи версгш Windows. При исполб- 
зовангш МШ-версгш (Multilingual User Interface) Windows зто своиство можно 
задатв с помогцбго утилитБ1 Regional and Language Options (Пзмк и регаоналБнме 
стандартБг) панели управлентш. 


ВНИМАНИЕ 

В типе String определено несколБко вариантов перегрузки методов Equals, StartsWith, 
EndsWith и Compare помимо тех, что приведенм ранее. Microsoft рекомендует избегатБ 
других версии (не представленнмх в зтои книге). Кроме того, нежелателБно исполб- 
зоватБ и другие имекзш,иесл в String методм сравненил — CompareTo (необходимБ 1 и 
дпл интерфеиса IComparable), CompareOrdinal и операторм == и !=. Причина втом, что 
вБ13Б1вак)1ции код не определиет лвно, как должно вмполнлтбсл сравнение строк, а на 
основании метода нелБЗч узнатБ, какои способ сравненил вмбран по умолчаникз. На- 
пример, по умолчаникз метод CompareTo внполнчет сравнение с учетом регионалБних 
стандартов, а Equals — без учета. Если вм лвно указмваете, как должно вмполнлтбсл 
сравнение строк, ваш код будет проиде читатБ и сопровождатБ. 


□ CurrentCulture исполБзуетсн во всех случаих, в которвгх не исполБзуетси 
своиство CurrentUICulture, в том числе дли форматировангш чисел и дат, при- 
веденгш и сравненгш строк. При форматировании требуготси обе части обвекта 
Culturelnfo — информации о нзвпсе и стране. По умолчаниго при создании 
потока зто своиство потока задаетсн \\ 1 п, 32 -фупк'ци(‘и GetUserDefaultLCID на 
основангш оОЂСКта Culturelnf о. Его можно задатв на вкладке Regional Options 
(РегионалБнме параметрБг) утилитБг Regional and Language Options (Пзбгк и ре- 
гионалБНБге стандартБг) панели управленгш. 

Значенгш по умолчаниго длл зтих двух своиств потоков, исполвзуемБге при 
создании потока, можно переопределитБ — длл зтого следует задатБ статические 
своиства DefaultThreadCurrentCulture и DefaultThreadCurrentUICulture обв- 
екта Culturelnfo. 

Во многих приложенгшх своиствам CurrentUICulture и CurrentCulture задаетсн 
один обкект Culturelnf о, то еств в них содержитсн одинакован информацгш о нзвгке 
и стране. Однако она может раз.личаткси. Например, в приложенгш, работагогцем 
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в США, все злементм интерфеиса могут представлнтБСн на испанском лзмке, а ва- 
лгота и формат дата — в соответствии с принлтмми в США стандартами. Длн зтого 
своиству CurrentUICulture потока задаетсл обвект Culturelnfo, инициализирован- 
нми с лзмком es (испанскии), а своиству CurrentCulture — обвект Culturelnfo, 
инициализированнми парои en-US. 

Внутренннн реализации обвекта Culturelnfo ссмлаетсл на обвект System. 
Globalization . Comparelnfo, инкапсулиругогции приннтме в даннмх регионалБнмх 
стандартах таблицм сортировки в соответствии с правилами К)никода. Исполб- 
зование регионалг>нмх стандартов при сортировке строк демонстрирует пример: 

using System; 

using System.Globalization; 

public static class Program { 
public static void Main() { 

String sl = "Strasse"; 

String s2 = "StraBe"; 

Boolean eq; 

// CompareOrdinal возврацает ненулевое значение 
eq = String.Compare(sl, s2, StringComparison.Ordinal) == 0; 
Console.WriteLine("Ordinal comparison: '{0}' {2} '{1}’", sl, s2, 
eq ? "==" : "!="); 

// Сортировка строк длн немецкого лзука (de) в Германии (DE) 

Culturelnfo ci = new CultureInfo("de-DE"); 

// Compare возврацает нулц 

eq = String.Compare(sl, s2, true, ci) == 0; 

Console.WriteLine("Cultural comparison: '{0}' {2} '{1}'", sl, s2, 
eq ? "==" : "!="); 

} 


B ре.зу./њтатс компоновки и вмполненин кода получим следугогцее: 

Ordinal comparison: 'Strasse' != ’StraBe' 

Cultural comparison: ’Strasse' == 'StraBe' 

ПРИМЕЧАНИЕ 

Если метод Compare не вмполнлет простое сравнение, то он производит расширение 
символов (character expansions), то есљ разбивает сложнме символб 1 на несколцко 
символов, игнорирул pernoHaabHbie стандартм. В предмдуидем случае немецкии 
символ 15 всегда расширлетсл до ss. Аналогично лигатурнми символ М всегда рас- 
ширнетсл до АЕ. Позтому в приведенном примере вмзов Compare будет всегда 
B03Bpauj,aTb 0 независимо от вмбраннмх регионалинмх стандартов. 


В некотормх редких случаих требуетси более тонкии контролв при сравне- 
нии строк длл проверки на равенство и длн сортировки. Например, зто может 


Тип System.String 367 


потребоватћсл прп сравнении строк с лпонскими иероглифами. Длл зтого ис- 
полБзуетсл своиство Comparelnfo обвекта Culturelnfo. Как отмечалосв ранее, 
оођскт Comparelnfo инкапсулирует таблицБг сравненгш символов дли различнБгх 
регионалБНБгх стандартов, причем длл каждого регионалБного стандарта сугцествует 
толбко один обвект Comparelnfo. 

При вБгзове метода Compare класса String исполБзуготсл указаннћге вћгзБшаго- 
гцим потоком регионалБНБге стандартБг. Если регионалБНБге стандартБг не указанБц 
исполБзуготсн значенин своиства CurrentCulture вБгзвшагогцего потока. Код, реали- 
зугогции метод Compare, получает сскшку на обвект Comparelnfo соответствугогцего 
регионалБного стандарта и вБИБшает метод Compare обвекта Comparelnfo, пере- 
давал соответствугогцие параметрвг (например, признак игнорировангш регистра 
символов). Естественно, если требуетсл дополнителвнБш контролБ, вбг должнбг 
самостолтелБно вБгзБшатБ метод Compare конкретного обвекта Comparelnfo. 

Метод Compare класса Comparelnfo принимает в качестве параметра значение 
перечислимого типа CompareOptions. Битовбш флаги можно обБединнтБ посред- 
ством оператора «или» длн болвшего контроли над сравнением строк. За полнбгм 
описанием флагов обрагцаитесв к документации .NET Framework. 

Следугогции пример демонстрирует значение регионалБНБгх стандартов при 
сортировке строк и различнвге вариантБг сравненгш строк: 

using System; 
using System.Text; 
using System.Windows.Forms; 
using System.Globalization; 
using System.Threading; 

public sealed class Program { 
public static void Main() { 

String output = String.Empty; 

Stringf] symbol = new String[] { "=", ">" }; 

Int32 х; 

Culturelnfo ci; 

// Следукнции код демонстрирует, насколико отличаетсн резулитат 
// сравненин строк длн различних регионалннмх стандартов 
String sl = "cote"; 

String s2 = "cote"; 

// Сортировка строк длл французского дзика (Францин) 
ci = new CultureInfo("fr-FR"); 
х = Math.Sign(ci.CompareInfo.Compare(sl, s2)); 
output += String.Format("{0} Compare: {1} {3} {2}", 
ci.Name, sl, s2, symbol[x + 1]); 
output += Environment.NewLine; 

// Сортировка строк длд нпонского дзмка (Лпонин) 
ci = new CultureInfo( "ја-ЗР"); 
х = Math.Sign(ci.CompareInfo.Compare(sl, s2)); 

продолжение & 
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output += String.Format( "{0} Compare: {1} {3} {2}", 
ci.Name, sl, s2, symbol[x + 1]); 
output += Environment.NewLine; 

// Сортировка строк по регионале.нум стандартам потока 
ci = Thread.CurrentThread.CurrentCulture; 
х = Math.Sign(ci.CompareInfo.Compare(sl, s2)); 
output += String.Format("{0} Compare: {1} {3} {2}", 
ci.Name, sl, s2, symbol[x + 1]); 

output += Environment.NewLine + Environment.NewLine; 

// Следукхции код демонстрирует исполнзование дополнителвнмх возможностеи 
// метода Comparelnfo.Compare при работе с двумв строками 
// на лпонском лзмке 

// Зти строки представлвктг слово "shinkansen" (название 
// високоскоростного поезда) в разннх вариантах писвма: 

// хирагане и катакане 

sl = " "; // ( "\u3057\u3093\u304b\u3093\u305b\u3093" ) 
s2 = " "; // ("\u30b7\u30f3\u30ab\u30f3\u30bb\u30f3") 

// Резулитат сравненил по умолчанит 
ci = new CultureInfo("ja-3P"); 
х = Math.Sign(String.Compare(sl, s2, true, ci)); 
output += String.Format("Simple {0} Compare: {1} {3} {2}", 
ci.Name, sl, s2, symbol[x + 1]); 
output += Environment.NewLine; 

// Резулитат сравненил, которми игнорирует тип канм 
Comparelnfo comparelnfo = CompareInfo.GetCompareInfo("ja-3P"); 
х = Math.Sign(compareInfo.Compare(sl, s2, 

CompareOptions.IgnoreKanaType)); 
output += String.Format("Advanced {0} Compare: {1} {3} {2}", 
ci.Name, sl, s2, symbol[x + 1]); 

MessageBox.Show(output, "Comparing Strings For Sorting"); 


ПРИМЕЧАНИЕ 

Подобнњ 1 е фаилв! c исходннм кодом нелвзл сохранитв в кодировке ANSI, посколЕ.ку 
иначе лпонские символв! будут потеринн. Длв того 4To6bi сохранитв зтот фаил при 
помоиди MicrosoftVisual Studio, откроите диалоговоеокно Save File As, раскроите спи- 
сокформатовсохраненил и вмберите вариант SaveVVith Encoding. 'Л вмбрал (Оникод 
(UTF-8 with signature) — Codepage 65001. Компиллтор C# успешно разбирает фаилм 
программного кода, исполвзукицие зту кодовукз страницу. 


После построении и вмполнешш кода получим резулцтат, показаннми на 
.14.1. 
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Comparing Strings For Sorting X 


fr-FR Compare: cote > сб:е 
ja-JP Compare: cote < cote 
en-US Compare: cote < cote 

Simple ja-JP Compare: 1 >/j№A/&/u > V'JtLr tZ^ 
Advanced ja-JP Compare: [jhjfi'hAthj = 'ЈУЈјУИУ 


Рис. 14.1. Резулетат сортировки строк 


Помимо Compare, класс Comparelnfo предлагает методм IndexOf , IsLastIndexOf , 
IsPrefix и IsSuffix. Благодари имегогцеисн у каждого из зтих методов перегру- 
женнои версии, которои в качестве параметра передаетсл значение перечислимого 
типа CompareOptions, вм получаете дополнителБнме возможности по сравнентпо 
с методами Compare, IndexOf, LastIndexOf, StartsWith и EndsWith класса String. 
Кроме того, следует иметБ в виду, что в FCL еств класс System.StringComparer, 
которБги также можно исполБЗОватБ длл сравнении строк. Он оказвшаетсл кстати 
в тех случалх, когда необходимо многократно вбшолнитб однотипнБге сравненгш 
множества строк. 


Интернирование строк 

Как н уже отмечал, сравнение строк исполвзуетси во многих приложенгшх, однако 
зта операцгш может огцутимо сказатвсн на производителБности. При порлдковом 
сравнении (ordinal comparison) CLR бпгстро провернет, равно ли количество симво- 
лов в строках. При отрицателвном резулБтате строки точно не равнБг, но если длина 
одинакова, приходитсн сравниватв их символ за символом. При сравнении с учетом 
региоиалБНБгх стандартов среде CLR тоже приходитсл посимволбио сравнитБ строки, 
потому что две строки разнои длгшбг могут оказатБСи равнБгми. 

К тому же хранение в памити несколвких зкземплнров однои строки приводит 
к иепроизводителБНБш затратам памлти — ведБ строки неизменнемБг Зффектив- 
ного исполБЗОвангш памлти можно добитвси, если держатБ в неи одну строку, на 
которуго будут указвшатБ соответствугогцие ссбглки. 

Если в приложении строки сравниваготсн часто методом поридкового сравне- 
нгш с учетом регистра или если в приложенгш ожидаетсл понвление множества 
одинаковмх строковвгх обвектов, то дли повБштенгш производителБности надо при- 
менитБ поддерживаемБш CLR механизм интернированш строк (string interning). 
При инициализации CLR создает внутреннгого хеш-таблицу, в которои клгочами 
ивлнготсл строки, а значенгшми — ссбшки на строковБге обвектБг в управлиемои 
куче. Вначале таблица, разумеетсл, пуста. В классе String еств два метода, предо- 
ставлигогцие доступ к внутреннеи хеш-таблице: 

public static String Intern(String str); 
public static String IsInterned(String str); 
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Первћш из них, Intern, шцет Stning во внутреннеи хеш-таблице. Если строка 
обнаруживаетсн, возвратцаетсл ссћшка на соответствукшдии обвект Stning. Иначе 
создаетсн копин строки, она добавлнетсл во внутреннкио хеш-таблицу, и возвратца- 
етсл ссвшка на копшо. Если приложение болкше не удерживает ссвшку на исход- 
HKiii обвект Stning, уборвдик мусора вправе освободитв памлтБ, занимаемуго зтои 
строкои. Обратите внимание, что уборшик мусора не вправе освободитв строки, на 
KOTopbie ссБшаетсн внутренннн хеш-таблица, посколвку в неи самои еств ссбшки 
на зти Stning. ОбвектБ 1 Stning, на которме ссншаетсл внутренннн хеш-таблица, 
нелБЗн освободитБ, пока не вБшружен соответствуклции домен приложении или 
не закрв 1 т поток. 

Как и Intenn, метод Islntenned получает параметр Stning и шцет его во 
внутреннеи хеш-таблице. Если поиск удачен, Islntenned возврагцает ссвшку на 
интернированнук) строку. В противном случае он возврагцает null, а саму строку 
не вставлнет в хеш-таблицу. 

По умолчаншо при загрузке сборки CLR интернирует все литералвнБШ строки, 
omicamibie в метаданшлхсборки. Вбшснилосб, что зто отрицателБно сказБшаетсн на 
производителБности из-за необходимости дополнителБного поиска в хеш-таблицах, 
позтому Microsoft теперв позволиет отклгочитб зту <<функциго>>. Если сборка от- 
мечена атрибутом System.Runtime.CompilenSenvices.CompilationRelaxations 
Attnibute, определнкнцим значение флага System.Runtime.CompilerServices. 
CompilationRelaxations. NoStninglntenning, то в соответствии со спецификациеи 
ЕСМА среда CLR может отказатвсн от интернировашш строк, определеннБ 1 х в ме- 
таданнБ 1 х сборки. Обратите внимание, что в целнх поввшенин производителБности 
работБ 1 приложенгш компиллтор C# всегда при компилиции сборки определлет 
зтот атрибут/флаг. 

Даже если в сборке определен зтот атрибут/флаг, CLR может предпочеств 
интернироватБ строки, но на зто не стоит рассчиткшатБ. Никогда не стоит писатк 
код, рассчитаннБ1и на интернирование строк, если толбко bki сами в своем коде 
ивно не вБ13Бшаете метод Intenn типа Stning. Следугогции код демонстрирует 
интернирование строк: 

String sl = "Hello"; 

String s2 = "Hello"; 

Console.WriteLine(Object.ReferenceEquals(sl, s2)); // Должно бмти 'False’ 

sl = String.Intern(sl); 
s2 = String.Intern(s2); 

Console.WriteLine(Object.ReferenceEquals(sl, s2)); // ’True' 

При первом вБ130ве метода RefenenceEquals переменнан sl ссвшаетсл на о6б- 
ект-строку "Hello" в куче, а s2 — на другуго обвект-строку "Hello". Посколвку 
ссбшки paaiibie, вбшодитсл значение False. Однако если вбшолнитб otot код в CLR 
версии 4.5, будет ввшедено значение Т nue. Дело в том, что зта верстш CLR игно- 
рирует атрибут/флаг, созданнвш компиллтором С#, и интернирует литералБнуго 
строку "Hello" при загрузке сборки в домен приложении. Зто означает, что sl и s2 
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ссмлаготсл на одну строку в куче. Однако, как уже отмечалосв, никогда не стоит 
писатБ код с расчетом на такое поведение, потому что в последугогцих версинх зтот 
атрибут/флагможет приниматБСн во внимание, и строка "Hello" интернироватБСн 
не будет. В деиствителБности, CLR версии 4.5 учитБ 1 вает зтот атрибут/флаг, но 
толбко если код сборки создан с помогцбго утилитБг NGen.exe. 

Перед вторБгм вбгзовом метода ReferenceEquals строка "Hello" нвно интерни- 
руетси, в резулвтате sl ссБшаетсл на интернированнуго строку "Hello". Затем при 
повторном вБгзове Intern переменнои s2 присваиваетсн ссвшка на ту же самуго стро- 
ку "Hello", на которуго ссншаетсл sl. ТеперБ при втором ввгзове ReferenceEquals 
мб 1 гарантировано получаем резулвтат Т rue независимо от того, бвша ли сборка 
скомпилирована с зтим атрибутом/флагом. 

Теперв на примере посмотрим, как исполБЗОватБ интернирование строки длн по- 
вБгшенгш производителБности и сниженгш нагрузки на памнтБ. ПоказаннБги далее 
метод NumTimesWordAppearsEquals принимает два аргумента: слово и массив строк, 
в котором каждвш злемент массива ссвшаетси на одно слово. Метод определлет, 
сколбко раз указанное слово содержитсл в списке слов, и возврагцает число: 

private static Int32 NumTimesWordAppearsEquals(String word, String[] 
wordlist) { 

Int32 count = 0; 

for (Int32 wordnum = 0; wordnum < wordlist.Length; wordnum++) { 
if (word.Equals(wordlist[wordnum], StringComparison.Ordinal)) 
count++; 

} 

return count; 

} 

Как видите, зтот метод ввгзБгвает метод Equals типа String, которБш сравнивает 
отделвнБге символбг строк и провернет, все ли символбг совпадагот. Зто сравнение 
может вбшолнитбси медленно. Кроме того, массив wordlist может иметв много 
злементов, которвге ссБшаготсч на многие обвектБг String, содержагцие тот же на- 
бор символов. Зто означает, что в куче может сугцествоватв множество идентичнвгх 
строк, которкге не должнбг уничтожатБСи в процессе уборки мусора. 

А теперв посмотрим на версиго зтого метода, котораи написана с интернирова- 
нием строк: 

private static Int32 NumTimesWordAppearsIntern(String word, String[] 
wordlist) { 

// B атом методе предполагаетсп, что все алементт в wordlist 

// ccbmaiOTcn на интернированние строки 

word = String.Intern(word) ; 

Int32 count = 0; 

for (Int32 wordnum = 0; wordnum < wordlist.Length; wordnum++) { 
if (Object.ReferenceEquals(word, wordlist[wordnum])) 
count++; 

} 

return count; 

} 
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Зтот метод интернирует слово и предполагает, что wordlist содержит ссмлки 
на интернированнме строки. Во-первмх, в зтои версии зкономитси памнтБ, если 
слово повторлетсл в списке слов, потому что теперв wordlist содержит много- 
численнме ссмлки на единственнми обвект String в куче. Во-втормх, зта версгш 
работает бмстрее, потому что длн вмисненгш, естБ ли указанное слово в массиве, 
достаточно простого сравненгш указателеи. 

Хотл метод NumTimesWordAppearsIntern работает бмстрее, чем NumTimes- 
WordAppearsEquals, обгцал производителБностБ приложенгш может оказатнсл 
ниже, чем при исполБзовании метода NumTimesWordAppearsIntern из-за вре- 
мени, которое требуетсл на интернирование всех строк по мере добавленин их 
в массив wordlist (соответствугогции код не показан). Преимугцества метода 
NumTimesWordAppearsIntern — ускорение работвг и снижение потребленгш па- 
млти — будут заметнБг, если приложениго нужно множество раз вБгзвгватБ метод, 
передаван одггн гг тот же массив wordlist. Зтггм обсуждением н хотел донести до вас, 
что интернирование строк полезно, но исполвзоватБ его нужно с осторожностнго. 
Собственно, именно по зтои причине компилитор C# указвгвает, что не следует 
разрешатв интернирование строк. 


Создание пулов строк 

При обработке исходного кода компиллтор должен каждуго литералвнуго строку 
поместитБ в метаданнвге управлиемого модулл. Если одна строка встречаетсл 
в исходном коде много раз, размегцение всех таких строк в метаданнвгх приведет 
к увеличениго размера резулвтиругогцего фаила. 

Что6бг не допуститБ роста обвема кода, многие компиллторБг (в том числе С#) 
храннт литералБнуго строку в метаданнвгх модули толбко в одном зкземплнре. Все 
упомгшангш зтои строкгг в исходном коде компилитор замениет ссвглками на ее 
зкземплир в метаданнвгх. Благодари зтому заметно уменБшаетсн размер модули. 
Способ не нов — в компилнторах Microsoft С/С++ зтот механизм реализован уже 
давно и назвгваетсл созданием пула строк (string pooling). Зто егце одно средство, 
позволнгогцее ускоритв обработку строк. Полагаго, вам будет полезно знатв о нем. 

Работа с символами и текстовмми злементами в строке 

Сравнение строк полезно при сортировке гг поггске одинаковвгх строк, однако ггногда 
требуетсн провернтБ отделБНБге символбг в пределах строкгг. С подобнвгми задачами 
призванБг справлитБСн несколБКО методов и своиств типа String, в числе которвгх 
Length, Chars (индексатор в С#), GetEnumerator, ToCharArray, Contains, IndexOf , 
LastIndexOf, IndexOfAny и LastIndexOfAny. 

Ha самом деле System. Char представлиет одно 16-разрндное кодовое значение 
в кодировке КЗнггкод, которое необнзателвно соответствует абстрактному ЈОнггкод- 
символу. Так, некоторвге абстрактнвге Unicode -символБг нвлнготси комбинациеи 
двух кодовбгх значенгш. Например, сочетание символов U+0625 (арабскаи буква 
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«алеф» с подстрочнои «хамза») и U+0650 (арабскан «казра») образует один араб- 
скии символ, или текстовип алемент. 

Кроме того, представление некотормх текстовмх алементов требует не одного, 
адвух 16-разрнднмхкодовмхзначении. Первое назмвагот старшим (high surrogate), 
а второе — младшим заменителем (low surrogate). Значенгш старшего находлтсл 
в диапазоне от U+D800 до U+DBFF, младшего — от U+DCOO до U+DFFF. Такои 
способ кодировки позволнет представитБ в Unicode более миллиона различнБгх 
символов. 

СимволБг-заменители востребованБг в основном в странах Восточнои Азии и го- 
раздо менвше в США и Европе. Дли корректнои работБ 1 с текстовБ 1 ми злементами 
предназначен тип System .Globalization . Stninglnfo. Самнш простои способ 
восполБЗОватБСл зтим типом — создатБ его зкземплнр, передав его конструктору 
строку. Чтобвг затем узнатБ, сколбко текстовБ 1 х злементов содержит строка, до- 
статочно прочитатв своиство LengthInTextElements обвекта Stninglnfo. Позже 
можно вБгзватБ метод SubstningByTextElements обвекта Stninglnfo, чтобкг извлечБ 
один или несколБКО последователБНБгх текстовБ1х злементов. 

Кроме того, в классе Stninglnf о еств статическии метод GetTextElementEnumenaton, 
возврашагошии обвект System.Globalization.TextElementEnumenaton, которвш, 
в свок) очередв, позволнет просмотретв в строке все абстрактнвге символбг К)никода. 
Наконец, можно восполБЗОватБСн статическим методом PanseCombiningChanactens 
типа Stninglnfo, что 6 бг получитБ массив значении типа Int32, по длине которого 
можно судитв о количестве текстоввгх злементов в строке. Каждвш злемент мас- 
сива содержит индекс первого кодового значенгш соответствугогцего текстового 
злемента. 

Очереднои пример демонстрирует различнвге спосо 6 б 1 исполБЗОвангш класса 
Stninglnfo длн управлении текстоввгми злементами строки: 

using System; 
using System.Text; 
using System.Globalization; 
using System.Windows.Forms; 

public sealed class Program { 
public static void Main() { 

// Следункцал строка содержит комбинированнме символм 
String s = "a\u0304\u0308bc\u0327" ; 

SubstringByTextElements(s); 

EnumT extElements(s); 

EnumTextElementIndexes(s); 

} 

private static void SubstringByTextElements(String s) { 

String output = String.Empty; 

Stringlnfo si = new Stringlnfo(s); 

for (Int32 element = 0; element < si.LengthInTextElements; element++) { 
output += String.Format( 
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"Text element {0} is 

elementj si.SubstringByTextElements(element, 1), 
Environment.NewLine); 

} 

MessageBox.Show(output, "Result of SubstringByTextElements"); 

} 

private static void EnumTextElements(String s) { 

Stning output = String.Empty; 

TextElementEnumerator charEnum = 

StringInfo.GetTextElementEnumerator(s); 
while (charEnum.MoveNext()) { 
output += String.Format( 

"Character at index {0} is '{1}'{2}"д 
charEnum.Elementlndex, charEnum.GetTextElement(), 
Environment.NewLine); 

} 

MessageBox.Show(output, "Result of GetTextElementEnumerator"); 

} 

private static void EnumTextElementIndexes(String s) { 

String output = String.Empty; 

Int32[] textElemIndex = Stringlnfo.ParseCombiningCharacters(s); 
for (Int32 i = 0; i < textElemIndex.Length; i++) { 
output += String.Format( 

"Character {0} starts at index {1}{2}", 
i, textElemIndex[i], Environment.NewLine); 

} 

MessageBox.Show(output, "Result of ParseCombiningCharacters"); 

} 

} 


После компоновки и последуклцего запуска зтого кода на зкране понвнтсп ин- 
формационнне окна (рис. 14.2-14.4). 
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Рис. 14.2. Резулвтат 
работи метода 
SubstringByTextElements 


Рис. 14.3. РезулБтат 
pa6oTbi метода 
GetTextElementEnumerator 


Рис. 14.4. РезулБтат 
pa6oTbi метода 
ParseCombiningCharacters 
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Прочие операции со строками 

В табл. 14.1 представленм методм типа Stning, предназначеннме длн полного или 
частичного копировангш строк. 


Таблица 14 . 1 . Методн копированич строк 


Член 

Тип метода 

Описание 

Clone 

Зкземшшрнвги 

Возврагцает ссБшку на тот же самБги обвект (this). Зто 
нормалБно, так как обЂектБг String неизменнемБг. Зтот 
метод реализует интерфеис ICloneable класса String 

Сору 

Статическии 

Возврагцает новуго строку — дубликат заданнои стро- 
ки. ИсполБзуетсл редко и нужен толбко длл приложе- 
нии, обрабатБшагогцих строки как лексемн. 06бшно 
строки с одинаковБгм набором символов интерни- 
руготсл в одну строку. Зтот метод, напротив, создает 
новБги строковБги обвект и возврагцает инои указателв 
(ссБшку), хотл в строках содержатсл одинаковБге сим- 

ВОЛБ1 

СоруТо 

ЗкземплнрнБги 

Копирует группу символов строки в массив символов 

Substring 

ЗкземпллрнБги 

Возврашает новуш строку, представллгошук) частБ 
исходнои строки 

ToString 

ЗкземплнрнБги 

Возврагцает сснлку на тот же обвект (this) 


Помимо зтих методов, у типа Stning естБ много статических и зкземплирнБгх 
методов длн различнБгх операции со строками: Insent, Remove, PadLeft, Replace, 
Split, ioin, ToLowen, ToUppen, Tnim, Concat, Fonmat и пр. Еше раз повторго, что все 
зти методћг возврагцагот новвге строковБге обвектБг; создатБ строку можно, но из- 
менитБ ее нелБЗи (при условии исполБЗОвантш безопасного кода). 


Зффективное создание строк 

Тип Stning представлнет собои неизменнемуго строку, а длн динамических операции 
со строками и символами при создании обвектов Stning в FCL имеетсн тип System . 
Text . StningBuilden. Его можно рассматриватв как некии обгцедоступнБш кон- 
структор длн Stning. В обгцем случае нужно создаватБ методБг, у которБгх в качестве 
параметров ввгступагот обвектБг Stning, а не StningBuilden, хотл можно написатБ 
метод, возврагцагогции строку, создаваемуго динамически внутри метода. 

У обвекта StningBuilden предусмотрено поле со ссбшкои на массив структур 
Chan. ИсполБзун членБг StningBuilden, можно зффективно манипулироватБ зтим 
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массивом, сокрашли строку и изменин символм строки. При увеличении строки, 
представлнкзшеи ранее вмделеннми массив символов, StningBuilder автоматиче- 
ски вмделит памнтБ длн нового, болБшего по размеру массива, скопирует символб1 
и приступит к работе с новбш массивом. А прежнии массив попадет в сферу деи- 
ствии уборгцика мусора. 

Сформировав свок) строку с помошмо обвекта StringBuilden, «преобразуите» 
массив символов StringBuilder в обвект String, вБ 13 вав метод ToString типа 
StringBuilder. Зтот метод просто возврагцает ссћшку на поле-строку, управлнемуго 
оођоктом StringBuilder. Посколвку массив символов здесв не копируетсл, метод 
вБшолннетсн оченп бБ1Стро. Обвект String, возврагцаемБш методом ToString, не 
может 6б1тб изменен. Позтому, если bhi вБВОвете метод, которвш попБ1таетси изме- 
нитб строковое поле, управлнемое обвектом StringBuilder, методвг зтого обвекта, 
знаи, что длн него 6бш вБ 13 ван метод ToString, создадут новбш массив символов, 
манипулиции с kotopbim не повлгшгот на строку, возврагценнуго предвгдугцим вбг- 
зовом ToString. 

Создание обвекта StringBuilder 

В отличие от класса String, класс StringBuilder в CLR не представлиет собои 
ничего особенного. Кроме того, болвшинство нзбгков (вклгочал С#) не считагот 
StringBuilder примитивнБш типом. Обвект StringBuilder создаетсл так же, как 
лгобои обвект непримитивного типа: 

StringBuilder sb = new StringBuilder( ); 

У типа StringBuilder несколвко конструкторов. Задача каждого из них — вбг- 
деллтБ памнтБ и инициализироватБ три внутренних полн, управлнемвгх лго6бш 
обвектом StringBuilder. 

□ МаксималБнан емкостБ (maximum capacity) — поле типа Int32, которое задает 
максималБное число символов, размегцаемвгх в строке. По умолчаншо оно равно 
Int32 . MaxValue (около двух миллиардов). Зто значение обвгчно не измениетсн, 
хотн можно задатв и менБшее значение, ограничивагогцее размер создаваемои 
строки. Длн уже созданного обвекта StringBuilder зто поле изменитв нелБЗи. 

□ Емкостб (capacity) — поле типа Int32, показБгвагогцее размер массива символов 
StringBuilder. По умолчаншо оно равно 16 . Если известно, сколбко символов 
предполагаетсл разместитв в StringBuilder, укажите зто число при создании 
обвекта StringBuilder. При добавленгш символов StringBuilder определлет, 
не вбгходит ли новбпг размер массива за установленнвги предел. Если да, то 
StringBuilder автоматически удваивает емкоств, и исходи из зтого значенгш, 
вБгделнет памнтБ под новбпг массив, а затем копирует символбг из исходного мас- 
сива в новбпг. Исходнбпг массггв в далвнеишем утилизируетсл сборгциком мусора. 
Динамггческое увелггчение массггва снггжает производителвностБ, позтому его 
следует избегатн, задавал подходигцуго емкоств в начале работвг с обвектом. 
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□ Массив символов (character аггау) — массив структур Chan, содержашии на- 
бор символов «строки». Число символов всегда менвше (или равно) емкости 
и максималБнои емкости. Количество символов в строке можно получитБ через 
своиство Length типа StningBuilder. Значение Length всегдаменБше или равно 
емкости StningBuilden. При создании StningBuilden можно инициализироватБ 
массив символов, передаваи ему Stning как параметр. Если строка не задана, 
массив первоначалвно не содержит символов и своиство Length возврагцает 0. 


Членм типа StringBuilder 

Тип StningBuilden в отличие от Stning представллет изменнемуго строку. Зто зна- 
чит, что многие членБ1 StningBuilden изменнгот содержимое в массиве символов, 
не создавал hobbix обвектов, размегцаемБ1х в управлиемои куче. StringBuilder 
вБгделнет памнтБ длн новбгх обвектов толбко в двух случалх: 

□ при динамическом построении строки, размер которои преввпнает установлен- 
нуго емкоств; 

□ при вБгзове метода ToStning типа StningBuilden. 

В табл. 14.2 представленв! методБ! класса StningBuilden. 


Таблица 14.2. Членн класса StringBuilder 


Член 

Тип члена 

Описание 

MaxCapacity 

Неизменлемое 

своиство 

Возврагцает наиболБшее количество символов, 
которое может 6нтб размепгено в строке 

Capacity 

Изменлемое 

своиство 

Получает/устанавливает размер массива 
символов. При попнтке установитв емкостБ 
менвшуго, чем длина строки, или болвше, 
чем MaxCapacity, генерируетсл исклгочение 

Argument Out OfRangeException 

EnsureCapacity 

Метод 

Гарантирует, что размер массива символов будет 
не менвше, чем значение параметра, передаваемого 
зтому методу. Если значение превБшгает текугцуго 
емкостБ обвекта StringBuilder, размер массива 
увеличиваетсл. Если текугцал емкоств болБше, чем 
значение, передаваемое зтому своиству, размер мас- 

сива не изменлетсл 

Length 

Изменлемое 

своиство 

Возврагцает количество символов в «строке». Зта 
величина может 6бгтб менБше текугцеи емкости 
массива символов. Присвоение зтому своиству зна- 
ченгш 0 сбрасвгвает содержимое и очшцает строку 
StringBuilder 
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Таблица 14.2 ( продолжение ) 


Член 

Тип члена 

Описание 

ToString 

Метод 

Версин без параметров возврагцает обвект String, 
представллгопЈии массив символов обвекта 
StringBuilder 

Chars 

Изменлемое 

своиство- 

индексатор 

Возвраш;ает из массива или устанавливает в масси- 
ве символ с заданнвгм индексом. В C# зто своиство- 
индексатор (своиство с параметром), доступ к ко- 
торому осугцествллетсл как к злементам массива 
(с исполБзованием квадратннх скобок []) 

Clear 

Метод 

Очшцает содержимое обвекта StringBuilder, анало- 
гично назначениго своиству Length значенил 0 

Append 

Метод 

Добавллет единичнни обвект в массив символов, 
увеличивал его при необходимости. Обвект преоб- 
разуетсл в строку с исполвзованием обгцего форма- 
та и с учетом регионалБнвгх стандартов, свлзаннвгх 
с ВБГзнвагогцим потоком 

Insert 

Метод 

Вставллет сдиттичини обвект в массив символов, 
увеличивал его при необходимости. Обвект преоб- 
разуетсл в строку с исполвзованием обгцего форма- 
та и с учетом регионалг>ннх стандартов, свнзанннх 

С ВБ13НВаГО1ЦИМ потоком 

AppendFormat 

Метод 

Добавллет заданнвге обвектн в массив символов, 
увеличивал его при необходимости. ОбЂектн пре- 
образуготсл в строку указанного формата и с учетом 
заданннх регионалвннх стандартов. Зто один из 
наиболее часто исполБзуемвтх методов при работе 
с обвектами StringBuilder 

AppendLine 

Метод 

Присоединнет пустуго строку в конец символвного 
массива, увеличивал его емкоств при необходимости 

Replace 

Метод 

Заменлет один символ или строку символов в мас- 
сиве символов 

Remove 

Метод 

Удаллет диапазон символов из массива символов 

Equals 

Метод 

Возврашает true, толбко если обЂектм StringBuilder 
имешт одну и ту же максималБнук) емкостБ, 
емкостБ и одинаковме символм в массиве 

СоруТо 

Метод 

Копирует подмножество символов StringBuilder 
в массив Char 


Отмечу одно важное обстоителБСтво: болБшинство методов StningBuilder 
возврашагот ссБшку на тот же обвект StringBuilder. Зто позволлет вБ1СтроитБ 
в цепочку сразу несколвко операции: 
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StringBuilder sb = new StringBuilder( ); 

String s = sb.AppendFormat("{0} {1}", "Deffrey", "Richter"). 

Replace(' '-').Remove(4, 3).ToString(); 

Console.WriteLine(s); // "Deff-Richter" 

У класса StningBuilder нет некотормх аналогов длл методов класса Stning. 
Например, у класса Stning естћметодм ToLowen, ToUppen, EndsWith, PadLeft, Tnim 
и т. д., отсутствукнцие у класса StningBuilden. В то же времн у класса StningBuilden 
естБ расширеннми метод Replace, вмполникнции замену символов и строк .типњ 
в части строки (а не во всеи строке). Из-за отсутствин полного соответствин 
между методами иногда приходитсл прибегатБ к преобразованинм между Stning 
и StningBuilden. Например, сформироватБ строку, сделатБ все буквм прописнмми, 
а затем вставитБ в нее другуго строку позволлет следугогции код: 

// Создаем StringBuilder длл операции со строками 
StringBuilder sb = new StringBuilder( ); 

// Внполннем рлд деиствии со строками, исполнзул StringBuilder 
sb.AppendFormat("{0} {1}" "Deffrey", "Richter" ). Replace( " ", "-"); 

// Преобразуем StringBuilder в String, 

// чтобм сделатц все символм прописнмми 
String s = sb.ToString().ToUpper(); 

// Очицаем StringBuilder (внделлетсл naMHTb под новии массив Char) 
sb.Length = 0; 

// Загружаем строку с прописнмми String в StringBuilder 
// и виполнлем осталн,нме операции 
sb.Append(s).Insert(8, "Marc-"); 

// Преобразуем StringBuilder обратно в String 
s = sb.ToString(); 

// Внводим String на зкран длл полБЗОвателв 
Console.WriteLine(s); // "3EFFREY-Marc-RICHTER" 

Зтот код неудобен и незффективен — и все из-за того, что StningBuilden не 
поддерживает все операции, которме может вмполнитб Stning. НадегосБ, в будугцем 
Microsoft улучшит класс StningBuilden, дополнив его необходимћши методами 
длл работБ! со строками. 


Получение строкового представленил 
обЂекта 


Часто нужно получитБ строковое представление обвекта, например, дли отобра- 
женил числового типа (такого, как Byte, Int32, Single и т. д.) и обвекта DateTime. 
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ПосколБку .NET Framework нвлиетсл обЂектно-ориентированнои платформои, то 
каждБш тип должен сам предоставитБ код, преобразуклции «значение» зкземплнра 
в некии строковми зквивалент. Вмбиран способм решенин зтои задачи, разработчи- 
ки FCL придумали паттерн программированин, предназначеннми длл повсеместного 
исполБЗОвангш. Рассмотрим зтот паттерн. 

Длн полученин представленин лгобого обвекта в виде строки надо вмзватБ метод 
ToStning. ПосколБку зтот открмтми виртуалБнми метод без параметров определен 
в классе System .Object, его можно вмзмватБ длл зкземплира лгобого типа. Се- 
мантически ToStning возврагцает строку, которал представлиет текугцее значение 
обвекта в формате, учитБшагогцем текугцие регионалБшде стандартБ1 вБгзвавшего 
потока. Строковое представление числа, к примеру, должно правилБно отображатБ 
разделителБ дробнои части, разделителБ групп разрндов и тому подобнБШ параметрБц 
устанавливаемБге регионалБНБши стандартами вБИБшагогцего потока. 

Реализацгш Т oStning в типе Sy stem . Ob ject просто возврагцает полное имн типа 
обвекта. В зтом значенгш мало полбзбц хотл длл многих типов такое решение по 
умолчаншо может оказатвсл единственно разумнвш. Например, как иначе пред- 
ставитБ в виде строки такие обвектБг, как FileStneam или Hashtable? 

Типбг, которБге хотлт представитБ текугцее значение обвекта в более содер- 
жателвном виде, должнб 1 переопределитБ метод ToStning. Все базоввге типбц 
встроеннБге в FCL (Byte, Int32, UInt64, Double и т. д.), имегот переопределеннБги 
метод ToStning, реализацтш которого возврагцает строку с учетом регионалвнБгх 
стандартов. В отладчике Visual Studio при наведенгш указателл мбшш на соответ- 
ствугогцуго переменнуго понвлнетси всплБшагогцан подсказка. Текст зтои подсказки 
формируетсл путем вБгзова метода ToStning зтого обвекта. Таким образом, при 
определенгш класса вбг должнбг всегда переопределнтБ метод ToStning, что6бг иметБ 
качественнуго поддержку при отладке программного кода. 


Форматм и регионалБнме стандартм 

У метода ToStning без параметров естБ два недостатка. Во-первБ 1 х, вБгзБшагогцал 
программа не управлнет форматированием строки, как, например, в случае, ког- 
да приложеншо нужно представитв число в денежном или деслтичном формате, 
в процентном или шестнадцатеричном виде. Во-вторБ 1 х, вБШБшагогцан программа не 
может вБгбратБ формат, учитБшагогции конкретнБге регионалБНБге стандартБк Вто- 
рои недостаток создает проблемБ1 скорее длл сервернБгх приложенгш, нежели длл 
кода на стороне клиента. Изредка приложеншо требуетсн форматироватБ строку с 
учетом регионалБНБ1х стандартов, отлнчнбгх от таковБгх у вБ13Бшагогцего потока. Длл 
управленгш форматнрованием строки нужна версгш метода ToStning, позволнгогцан 
задаватБ специалБное форматирование и сведенгш о регионалБНБгх стандартах. 

Тип может предложитБ вБгзБшагогцеи программе вБгбор форматировангш и ре- 
гионалБшлх стандартов, если он реализует интерфеис System . IFonmattable: 

public interface IFormattable { 

String ToString(String format, IFormatProvider formatProvider); 

} 
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В FCL у всех базовмх типов (Byte, SByte, Intl6/UIntl6, Int32/UInt32, Int64/ 
UInt64, Single, Double, Decimal и DateTime) естБ реализации зтого интерфеиса. Кро- 
ме того, естБ такие реализации и у некоторБ 1 Х других типов, например GUID. К тому 
же каждвш перечислимБш тип автоматически реализует интерфеис IFormattable, 
позволпкпции получитБ строковое вБфажение длл числового значентш, содержа- 
гцегоси в зкземплпре перечислимого типа. 

Метод ToStning интерфеиса IFormattable получает два параметра. Перввш, 
format, — зто строка, сообгцагогцаи методу способ форматировангш обвекта. Вто- 
poii, formatProvider, — зто зкземплир типа, которвш реализует интерфеис System . 
IFormatProvider. Зтот тип предоставллет методу ToString информациго о регио- 
налБНБ 1 х стандартах. Как — скоро узнаете. 

Тип, реализугогции метод ToString интерфеиса IFormattable, определлет до- 
пустимБге вариантБ 1 форматировангш. Если переданнан строка форматировашш 
неприемлема, тип должен генерироватв исклгочение System. FormatException. 

Многие типБ 1 FCL поддерживагот несколвко форматов. Например, тип DateTime 
поддерживает следукицие форматБ 1 : "d" — датБ 1 в кратком формате, "D" — датвг 
вполномформате, "g" — датБ1 в обгцемформате, "М" — формат «меснц/денБ>>, "s" — 
сортируемБге датБг, "Т" — времн, "u" — универсалБное времн в стандарте IS 0 8601, 
"U" — универсалБное времл в полном формате, "Y" — формат «год/меслц» и т. д. 
Все перечислимБге типб1 поддерживагот строки: "G " — обгцгш формат," F " — формат 
флагов, "D" — деслтичнБш формат и "X" — гпестнадцатеричнБш формат. Подробнее 
о форматировангш перечислимБгх типов см. главу 15. 

Кроме того, все встроеннвш числовбш типб 1 поддерживагот следугогцие строки: 
"С" — формат валгот, "D" — деслтичнвш формат, "Е" — научшли (зкспоненциалБ- 
нбш) формат, "F" — формат чисел с фиксированнои точкои, "G" — обгцгш формат, 
"N" — формат чисел, "р" — формат процентов, "R" — обратимвш (round-trip) формат 
и "X" — гнестнадцатеричнБш формат. Числовбго типб 1 поддерживагот также шаблонБ 1 
форматировангш длн случаев, когда о 6 бшнб 1 х строк форматировангш недостаточно. 
ШаблонБ 1 форматировангш содержат специалБНБге символбц позволнгогцие методу 
ToString данного типа отобразитв нужное количество цифр, место разделители 
дробнои части, количество знаков в дробнои части и т. д. Полнуго информациго 
о строках форматировангш см. в разделе .NET Framework SDK, посвигценном 
форматированиго строк. 

Если вместо строки форматировангш передаетсл null, зто равносилвно вБгзову 
метода ToString с параметром "G". Иначе говори, обвектБ 1 форматиругот себн сами, 
применнн по умолчаниго «обгции формат». Разрабатншаи реализациго типа, BHi6e- 
рите формат, которБш, по вашему мнениго, будет исполБЗОватвсц чагце всего; зто 
и будет «обгцгш формат». Кстати, вбгзов метода ToString без параметров означает 
представление обвекта в обгцем формате. 

Закончив со строками форматировангш, переидем к регионалвнБш стандартам. 
По умолчаниго форматирование ввшолннетсн с учетом регионалБНБ 1 х стандартов, 
свнзаннБ1х с вБ13Бшагогцим потоком. Зто своиственно методу Т oString без параме- 
тров и методу ToString интерфеиса IFormattable со значением null в качестве 
formatProvider. 
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Регионалћнме стандартм влингот на форматирование чисел (вклгочан денежнме 
суммм, целме числа, числа с плавагогцеи точкои и процентм), дат и времени. Метод 
ToStning длл типа Guid, представлнгогцего код GUID, возврагцает строку, отобра- 
жагогцуго толвко значение GUID. Регионалћнме стандартм врлд ли нужно учитмватБ 
при создании такои строки, так как она исполБзуетсл толбко самои программои. 

При форматировании числа метод ToString «анализирует» параметр 
formatProvider. Если зто null, метод ToString определлет регионалБнме стан- 
дартм, свнзаннме с вмзмвагогцим потоком, считмван своиство System . Threading . 
Thread . CurrentThread. CurrentCulture. Оно возврашает зкземплнр типа System . 
Globalization.Culturelnfo. 

Получив обвект, ToString считмвает его своиства NumberFormat длл форма- 
тировангш числа или DateTimeFormat длл форматировангш датм. Зти своиства 
возврашаготзкземплнрм System.Globalization.NumberFormatInfo и System. 
Globalization . DateTimeFormatlnf о соответственно. Тип NumberFormatlnf о опи- 
смвает группу своиств, таких как CurrencyDecimalSeparator, CurrencySymbol, 
NegativeSign, NumberGroupSeparator и PercentSymbol. Аналогично, у типа Date- 
TimeFormatlnfo описанм такие своиства, как Calendar, DateSeparator, DayNames, 
LongDatePattern, ShortTimePattern и TimeSeparator. Метод ToString считмвает 
зти своиства при создании и форматировании строки. 

При вмзове метода ToString интерфеиса IFormattable вместо null можно пере- 
датБ ссмлку на обвект, тип которого реализует интерфеис IFormatProvider: 

public interface IFormatProvider { 

Object GetFormat(Type formatType); 

} 

Основнаи идеи примененгш интерфеиса IFormatProvider такова: реализацгш 
зтого интерфеиса означает, что зкземплир типа «знает», как обеспечитБ учет реги- 
оналБНБ1х стандартов при форматировании, а регионалБнвге стандартБц свнзаннБге 
с вБИБшагогцим потоком, игнорируготси. 

Тип System.Globalization.CultureInfo — один из немногих определеншлх 
в FCL типов, в которвгх реализован интерфеис IFormatProvider. Если нужно 
форматироватв строку, скажем, длн Вкетнама, следует создатн обвект Culturelnfo 
и передатБ его ToString как параметр formatProvider. Вот как формиругот стро- 
ковое представление числа Decimal во вветнамском формате денежнои величинБК 

Decimal price = 123.54М; 

String s = price.ToString("C", new CultureInfo("vi-VN")); 

MessageBox.Show(s); 

Если собратБ и запуститБ зтот код, понвитсл информационное окно (рис. 14.5). 
Метод ToString типа Decimal, исходл из того, что аргумент formatProvider 
отличен от null, вБгзвгвает метод GetFormat обвекта: 

NumberFormatlnfo nfi = (NumberFormatlnfo) 

formatProvider.GetFormat(typeof(NumberFormatlnfo)); 
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123,54 đ 


ОК 


Рис. 14.5. Числовое значение во вветнамском формате денежнои величини 

Так ToStning запрашивает у обвекта (Culturelnfo) даннме о надлежашем фор- 
матировании чисел. Числовмм типам (вроде Decimal) достаточно получитБ .типњ 
сведенин о форматировании чисел. Однако другие типм (вроде DateTime) могут 
вмзмватБ GetFormat иначе: 

DateTimeFormatlnfo dtfi = (DateTimeFormatlnfo) 

formatProvider.GetFormat(typeof(DateTimeFormatlnfo) ) ; 

Раз параметр GetFormat может идентифицироватБ лгобои тип, метод достаточно 
гибок, что6б1 запрашиватБ лкзбуго форматнуго информациго. Сеичас типб1 ,NET 
Framework с помогцбго GetFormat запрашивагот информациго толбко о числах 
и дате/времени; в будугцем понвитсн возможностб запрашиватБ другие сведенгш. 

Кстати, чтобвг получитв строку длн обвекта, которкги не отформатирован в со- 
ответствии с определеннвгми регионалБНБгми стандартами, вБгзовите статическое 
своиство InvariantCulture класса System . Globalization . Culturelnf о и передаите 
возврагценнБги обвект как параметр formatProvider методу ToString: 

Decimal price = 123.54М; 

String s = price.ToString("C", Culturelnfo.InvariantCulture); 

MessageBox.Show(s); 

После компоновки и запуска зтого кода поивитсл информационное окно 
(рис. 14.6). Обратите внимание на перввги символ в вбгходнои строке: и. Он пред- 
ставлнет международное обозначение денежного знака (U+00A4). 



Рис. 14.6. Числовое значение в формате, представлл 10 шем 
абстрактнукз денежнукз единицу 
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Обмчно нет необходимости вмводитб строку в формате инвариантнБ 1 х регио- 
налБНБ 1 х стандартов. В типовом случае нужно просто сохранитБ строку в фаиле, 
отложив ее разбор на будушее. 

В FCL интерфеис I FormatProvider реализуетсн толбко тремл типами: 
уже упоминавшимсл типом Culturelnfo, а также типами NumberFormatlnfo 
и DateTimeFormatlnf о. Когда GetFormat вБШБшаетсн длн обвекта NumberFormatlnf о, 
метод провернет, нвлиетсл ли запрашиваемБпт тип NumberFormatlnf о. Если да, воз- 
врагцаетсл this, нет — null. Аналогичнвш образом вбиов GetFormat длл обвекта 
DateTimeFormatlnfo возврашдет this, если запрашиваемвш тип DateTimeFormatlnfo, 
и null — если нет. Реализацин зтого интерфеиса длп зтих двух типов упрогцает 
программирование. Чагце всего при получении строкового представленгш обвек- 
та вБИБшагогцан программа задает толбко формат, доволБСтвунсБ регионалБНБши 
стандартами, свнзаннБши с вБШБшагогцим потоком. Позтому обкино мбг вБИБшаем 
ToString, передаваи строку форматировангш и null как параметр formatProvider. 
Длл упрогценин работвг с ToString во многие типбг вклгоченБг перегруженнБге версгш 
метода ToString. Например, тип Decimal предоставллет четвгре перегруженнБгх 
метода ToString: 

// Зта версил визмвает ToString(null, null) 

// Сммсл: обшии формат, регионалБНћ 1 е стандарти потока 
public override String ToString(); 

// B атои версии виполнлетсв полнал реализацил ToString 
// Здесц реализован метод ToString интерфеиса IFormattable 
// Сммсл: и формат, и регионалнние стандарти задаттсл вћвмвагошеи программои 
public String ToString(String format, IFormatProvider formatProvider); 

// Зта версив просто вћвмвает ToString(format , null) 

// Сммсл : формат, заданнми вћвмваккцеи программои, 

// и регионалнние стандарти потока 
public String ToString(String format); 

// Зта версин просто вћвмвает ToString(null, formatProvider) 

// ЗдесБ реализуетсл метод ToString интерфеиса IConvertible 
// Сммсл: обтии формат и регионалинме стандарти, 

// заданнме вћвмваккцеи программои 

public String ToString(IFormatProvider formatProvider) ; 


Форматирование несколвких обвектов в одну строку 

До сих пор речБ шла о том, как конкретнБШ тип форматирует свои обЂектБт Однако 
иногда требуетсн сформироватБ строку из множества отформатированнвгх обвектов. 
В следугогцем примере в строку вклгочаготси дата, ими человека и его возраст: 

String s = String.Format ( "On {0}, {1} is {2} years old.", 
new DateTime(2012, 4, 22, 14, 35, 5), "Aidan", 9); 

Console.WriteLine(s); 
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Если собратР) и запуститћ зтот код в потоке с регионалБНБш стандартом en-US, 
на вБ 1 ходе получитсл строка: 

On 4/22/2012 2:35:05 РМ, Aidan is 9 yeans old. 

Статическии метод Format типа String получает строку форматированил, 
в которои подставллемБ1е параметрБ1 обозначенБ1 своими номерами в фигурнвш 
скобках. В зтом примере строка форматированин указвшает методу Format под- 
ставитБ вместо { 0 } перввш после строки форматированил параметр (текугцие 
дату и времн), вместо {1} — слсдуготции параметр (Aidan) и вместо {2} — третии, 
последнии параметр ( 9 ). 

Внутри метода Format дли каждого обвекта вБ13Бшаетсп метод ToString, полу- 
чагогции его строковое представление. Все возврагценнБ 1 е строки затем обљедини- 
10 'гси, а полученнБ 1 и резулБтат возврагцаетсл методом. Все 6 бшо 6 б 1 замечателБно, 
однако нужно иметк в виду, что ко всем обвектам применнетсл обгции формат 
и регионалБНБШ стандартБ1 вБИБшагогцего потока. 

Что6б 1 расширитБ стандартное форматирование обвекта, нужно добавитв внутрБ 
фигурнБ1х скобок строку форматировангш. В частности, следугогции код отлича- 
етсл от предБвдугцего толбко наличием строк форматировангш длл подставллемвгх 
параметров 0 и 2: 

String s = String.Format ( "On {0:D}, {1} is {2:E} years old.", 

new DateTime(2012, 4, 22, 14, 35, 5), "Aidan", 9); 

Console.WriteLine(s); 

Если собратв и запуститБ зтот код в потоке с регионалвнБш стандартом en-US, 
на вБгходе вбг увидите строку: 

On Sunday, April 22, 2012, Aidan is 9.000000E+000 years old. 

Разбираи строку форматировангш, метод Format «видит», что дли подставли- 
емого параметра 0 нужно вБгзвшатБ описаннБш в его интерфеисе IFormattable 
метод ToString, которому передаготсл в качестве параметров D и null. Аналогич- 
но, Format вБгзвшает метод ToString длл интерфеиса IFormattable параметра 2, 
передавал ему Е и null. Если у типа нет реализацгш интерфеиса IFormattable, то 
Format ввгзБшает его метод ToString без параметров, а в резулвтиругогцуго строку 
добавлиетсл формат по умолчаниго. 

У класса String еств несколБКО перегруженнБгх версии статического метода 
Format. В одну из нихпередаетснобвект, реализугогцииинтерфеис IFormatProvider, 
в зтом случае при форматировангш всех подставлнемвгх параметров можно при- 
меннтБ регионалБНБге стандартБг, задаваемБге вБгзБшагогцеи программои. Очевгвдно, 
Format вБИБшает метод ToString длн каждого обвекта, передаваи ему полученнвги 
обвект IFormatProvider. 

Если вместо String длл формировангш строки применнетсл StringBuilder, 
можно вБгзБгватв метод AppendFormat класса StringBuilder. Зтот метод ра- 
ботает так же, как Format класса String, за исклгочением того, что резулктат 
форматировангш добавлиетсл к массиву символов StringBuilder. Точно так же 
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в AppendFormat передаетсл строка форматировании и имеетсл версил, которои 
передаетсл IFormatProvider. 

У типа System. Console тоже естБ методБ1 Write и WriteLine, которБш передавзтсн 
строка форматированин и замешаемвш параметрБк Однако yConsole нет перегру- 
женнБ1х методов Write и WriteLine, позволпгогцих передаватв IFormatProvider. 
Если при форматировании строки нужно применитв определеннБге регионалБНБге 
стандартБг, вБгзовите метод Format класса String, передав ему нужнвш обвект 
IFormatProvider, а затем подставБте резулБтиругогцуго строку в метод Write или 
WriteLine класса Console. Зто не намного усложнит задачу, посколвку, как н уже 
отмечал, код на стороне клиента редко при форматировании применлет регионалв- 
нБге стандартБг, отличнБге от тех, что свизанБг с вБгзБшагогцим потоком. 


Создание собственного средства форматированив 

Уже на зтом зтапе поннтно, что платформа .NET Framework обладает вескма гибкими 
средствами форматировангш. EIo зто не все — вбг можете написатБ метод, которБги 
будет ББгзБшатБСл в AppendFormat типа StringBuilder независимо от того, длл 
какого обЂСКта вБшолннетси форматирование. Иначе говорн, длл каждого обвекта 
вместо метода ToString метод AppendFormat ввгзовет вашу функциго, котораи бу- 
дет форматироватБ один или несколБКО обвектов так, как вам нужно. Следугогцее 
описание относитси также к методу Format типа String. 

Попробуго поиснитб работу зтого механизма на примере. Допустим, вам нужен 
форматированнБги HTML -текст, которБш полБЗОвателБ будет просматриватБ 
в браузере, причем все значенгш Int32 должнбг вбшодитбсн полужирнБш шрифтом. 
Длн зтого вснкии раз, когда значение типа Int32 форматируетсл в String, нужно 
обрамлитв строку тегами полужирного шрифта: <В> и </В>. Следугогции фрагмент 
показБшает, как легко зто делаетсн: 

using Systemj 
using System.Text; 
using System.Threading; 

public static class Program { 
public static void Main() { 

StringBuilder sb = new StringBuilder(); 

sb.AppendFormat(new BoldInt32s(), "{0} {1} {2:M}", "3eff", 123, 

DateTime.Now); 

Console.WriteLine(sb); 

} 

} 

internal sealed class BoldInt32s : IFormatProvider, ICustomFormatter { 
public Object GetFormat(Type formatType) { 

if (formatType == typeof(ICustomFormatter)) return this; 
return Thread.CurrentThread.CurrentCulture.GetFormat(formatType); 

} 


public String Format(String format, Object arg, IFormatProvider 
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formatProvider) { 

String s; 

IFormattable formattable = arg as IFormattable; 

if (formattable == null) s = arg.ToString(); 

else s = formattable.ToString^formatj formatProvider); 

if (arg.GetType() == typeof(Int32)) 
return "<B>" + s + "</B>"; 
return s; 

} 


После компилиции и запуска кода в потоке с регионалвнмм стандартом en-US 
понвитсл строка (дата может отличатБСи): 

Deff <В>123</В> September 1 

Метод Main конструирует пустои обвект StningBuilden, к которому затем 
добавлиетсл форматированнан строка. При вв130ве AppendFonmat в качестве 
первого параметра подставлиетсн зкземплнр класса BoldInt32s. В нем, помимо 
рассмотренного ранее интерфеиса IFonmatPnoviden, реализован также интерфеис 
ICustomFonmatten: 

public interface ICustomFormatter { 

String Format(String format, Object arg, 

IFormatProvider formatProvider); 

} 


Метод Fonmat зтого интерфеиса вБИБшаетсл вснкии раз, когда методу Append- 
Fonmat класса StningBuilden нужно получитБ строку длл обвекта. Внутри зтого 
метода у нас понвлнетсл возможностб гибкого управленин процессом форматиро- 
вангш строки. Заглннем внутрв метода AppendFonmat, что 6 б 1 узнатБ поподробнее, 
как он работает. Следугогции псевдокод демонстрирует работу метода AppendFonmat: 

public StringBuilder AppendFormat(IFormatProvider formatProviderj 
String format, params Objectf] args) { 

// Если параметр IFormatProvider переданЈ вилснимЈ 
// предоставллет ли он обБект ICustomFormatter 
ICustomFormatter cf = null; 

if (formatProvider != null) 
cf = (ICustomFormatter) 

formatProvider.GetFormat(typeof(ICustomFormatter)); 

// Продолжаем добавллтБ литералвнме символи (не показанние 
// в зтом псевдокоде) и замецаемие параметри в массив символов 
// обБекта StringBuilder. 

Boolean MoreReplaceableArgumentsToAppend = true; 
while (MoreReplaceableArgumentsToAppend) { 


продолжение & 
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// argFormat ссмлаетсл на замешаемуго строку форматированил, 

// полученнук) из параметра format 
String argFormat = /* ... */; 

// argObj ссмлаетсл на соответствукпции злемент 
// параметра-массива args 
Object argObj = /* ... */; 

// argStr будет указмватн на отформатированнукз строку, 

// которал добавлпетсв к резулнтируккцеи строке 
String argStr = null; 

// Если ecTb специалинми обцект форматированив, 

// исполизуем его длп форматированип аргумента 
if (cf != null) 

argStr = cf.Format(argFormat, argObj, formatProvider); 

// Если специалиного обцекта форматированив нет или он не виполнпл 
// форматирование аргумента, попробуем eu;e что-нибудц 
if (argStr == null) { 

// Вулснпем, поддерживает ли тип аргумента 
// дополнителцное форматирование 
IFormattable formattable = argObj as IFormattable; 
if (formattable != null) { 

// Да; передаем методу интерфеиса длп зтого типа 

// строку форматированил и класс-поставшик 

argStr = formattable.ToString(argFormat, formatProvider) ; 

} else { 

// Нет; исполизуем обшии формат с учетом 
// регионалцнмх стандартов потока 
if (argObj != null) argStr = argObj.ToString(); 
else argStr = String.Empty; 

} 

} 

// Добавлпем символћ[ из argStr в массив символов (поле - член класса) 

/* ... */ 

// Проверлем, естц ли eu;e параметрм, нуждаккциесв в форматировании 
MoreReplaceableArgumentsToAppend = /* ... */; 

} 

return this; 

} 

Когда Main обрашаетсл к методу AppendFormat, тот вмзмвает метод GetFormat 
моего поставпдака формата, передаван ему тип ICustomFormatter. Метод GetFormat, 
описаннми в моем типе BoldInt32s, «видит», что запрашиваетсн ICustomFormatter, 
и возврагцает ссмлку на собственнми обвект, потому что он реализует зтот интер- 
феис. Если из GetFormat запрашиваетсл какои-то другои тип, и вмзмваго метод 
GetFormat длн обвекта Culturelnfo, свнзанного с вмзмвагогцим потоком. 

При необходимости форматироватБ замегцаемБП! параметр AppendFormat вбг- 
ЗБгваетсл метод Format класса ICustomFormatter. В моем примере вБгзвшаетсл 
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метод Format, описаннми моим типом BoldInt32s. В своем методе Format и про- 
верик), поддерживает ли форматируемми обвект расширенное форматирование 
посредством интерфеиса IFormattable. Если нет, то длн форматированин обвекта 
'А вмзмвак) простои метод ToString без параметров (унаследованнми от Object); 
если да — вмзмвак) расширеннми метод ToString, передавал ему строку формати- 
ровании и поставидика формата. 

Tenepb, имен форматированнук) строку, н провернк), имеет ли обвект тип Int32, 
и если да, заклгочак) строку в HTML -теги <В> и </В>, после чего возврагцаго полу- 
ченнуго строку. Если тип обвекта отличаетсл от Int32, просто возврагцаго форма- 
тированнуго строку без дополнителБнои обработки. 

Получение обг»екта посредством 
разбора строки 

В предмдушем разделе л рассказал о получении представленгш определенного 
обЂекта в виде строки. ЗдесБ м p>i поидем в обратном направлении: рассмотрим, как 
получитБ представление конкретнои строки в виде обвекта. ПолучатБ обвект из 
строки требуетсл не часто, однако иногда зто может оказатБСи полезнБш. В компа- 
нии Microsoft осознали важностБ формализации механизма, посредством которого 
строки можно разобратБ на o6n>eicn>i. 

Лгобои тип, способнБш разобратБ строку, имеет открБ1ТБ1и, статическии метод 
Ра rse. Он получает String, а на вигходе возврагцает зкземплнр данного типа; в каком- 
то смБгсле Parse ведет себн как фабрика. В ЕСЕметод Parse поддерживаетсл всеми 
числовБши типами, а также типами DateTime, TimeSpan и некоторБши другими 
(например, типами даннБгх SQL). 

Посмотрим, как получитБ из строки целочисленнБш тип. Все числовБге типбг 
(Byte,SByte, Intl6/UIntl6, Int32/UInt32, Int64/UInt64, Single, Double, Decimal 
и Biglnteger) имегот минимум один метод Parse. Вот как вбгглндит метод Parse 
д.;ш типа Int32 (длн других числовбгх типов методБг Parse вбпчшдлт аналогично). 

public static Int32 Parse(String s, NumberStyles style, IFormatProvider 

provider); 

Взглчнув на прототип, вб 1 сразу поимете сути работБ 1 зтого метода. Параметр s 
типа String идентифицирует строковое представление числа, которое необ- 
ходимо разобратБ длл полученил обвекта Int32. Параметр style типа System. 
Globalization .NumberStyles — зто набор двоичшлх флагов длн идентификации 
символов, которБге метод Parse должен наити в строке. А параметр provider типа 
IFormatProvider идентифицирует обвект, исполБзун которБП! метод Parse может 
получитБ информациго о регионалБНБгх стандартах, о чем речи шла ранее. 

Так, в следугогцем фрагменте при обрагцении к Parse генерируетсл исклгочение 
System . FormatException, так как в начале разбираемои строки находитсн пробел: 

Int32 х = Int32.Parse(" 123", NumberStyles.None, null); 



390 Глава 14. Символн, строки и обработка текста 


Чтобм «пропуститБ» пробел, надо вћиватБ Panse с другим параметром style: 

Int32 х = Int32.Panse(" 123", NumberStyles . AllowLeadingWhite, null); 

Подробнее o флагах и стандартнБ 1 х комбинацтшх, определеннБ 1 Х в типе 
NumbenStyles, см. документациго на .NET Framework SDK. 

Вот пример синтаксического разбора строки шестнадцатеричного числа: 

Int32 х = Int32.Parse("lA", NumberStyles.HexNumber, null); 

Console.WriteLine(x); // Отображает "26". 

Зтому методу Panse передаготсл три параметра. Длн удобства у многих типов 
еств перегруженнБге версии Panse с менвшим числом параметров. Например, у типа 
Int32 четвфе перегруженнБШ версии метода Panse: 

// Передает NumberStyles . Integer в качестве параметра стилл 
// и информации о регионалвннх стандартах потока 
public static Int32 Parse(String s); 

// Передает информацига o регионалцнмх стандартах потока 
public static Int32 Parse(String s, NumberStyles style); 

// Передает NumberStyles.Integer в качестве параметра стилл 
public static Int32 Parse(String s, IFormatProvider provider) 

// Тот метод, o котором л уже рассказал в зтом разделе 
public static int Parse(String s, NumberStyles style, 

IFormatProvider provider); 

У типа DateTime также еств метод Panse: 

public static DateTime Parse(String s, 

IFormatProvider provider, DateTimeStyles styles); 

Зтот метод деиствует подобно методу Panse длн числовбш типов за исклгочением 
того, что методу Panse типа DateTime передаетси набор двоичнбш флагов, описан- 
нб 1 х в перечислимом типе System.Globalization .DateTimeStyles, а не в типе 
NumbenStyles. Подробнее о флагах и стандартнвгх комбинацинх, определеннБ 1 х 
в типе DateTimeStyles, см. документациго на .NET Framework SDK. 

Длн удобства тип DateTime содержит три перегруженшлх метода Panse: 

// Передаетсл информацил о регионалцнћ 1 х стандартах потока, 

// а также DateTimeStyles . None в качестве стилл 
public static DateTime Parse(String s); 

// DateTimeStyles.None передаетсл в качестве стилл 

public static DateTime Parse(String s, IFormatProvider provider); 

// Зтот метод рассмотрен мнои в зтом разделе 
public static DateTime Parse(String s, 

IFormatProvider provider, DateTimeStyles styles); 
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Датм и времн плохо поддаготсн синтаксическому разбору. Многие разработчики 
столкнулисБ с тем, что метод Parse типа DateTime ухитрнетсн получитБ дату и времн 
из строки, в которои нет ни того, ни другого. Позтому в тип DateTime введен метод 
ParseExact, которми анализирует строку согласно некоему шаблону, показмвагогце- 
му, как должна вмглндетБ строка, содержагцаи дату или времи, и как вмполннтб ее 
разбор. О шаблонах форматированин см. раздел, посвншеннми DateTimeFormatlnf о, 
в документации на .NET Framework SDK. 

ПРИМЕЧАНИЕ 

Некоторме разработчики сообидили в Microsoft о следуклцем факте: если при много- 
кратном Bbi30Be Parse зтот метод генерирует исклкзчении (из-за невернмх даннђ 1 х, 
вводимих полвзователнми), зто отрицателвно сказмваетсл на производителвности 
приложенич. Длл такихтребукндих BbicoKon производителБности случаев в Microsoft 
создали MeTOflbi TryParse дпл всехчисловнхтипов данннх, длч DateTime, TimeSpan и 
даже длл IPAddress. Вот как вмглчдит один из двух перегруженннх методов TryParse 
типа Int32: 

public static Boolean TryParse(String s, NumbenStyles style, 

IFonmatPnovider pnovider, out Int32 nesult); 

Как видите, метод возвраш,ает true или false, информирул, удастсл ли разобрати 
строку в обвект Int32. Если метод возвра1дает1гие, переменнал, переданнав по ссилке 
в резулвтирукзидем параметре, будет содержатв полученное в резулктате разбора 
числовое значение. Паттерн ТгуХхх обсуждаетсл в главе 20. 

Кодировки: преобразованил между 
символами и баитами 

Win32-nporpaMMiiCTaM часто приходитсн писатд код, преобразугогции символм 
и строки из Unicode в Multi-Byte Character Set (MBCS). ПосколБку н тоже зтим 
занималси, могу авторитетно утверждатБ, что дело зто оченв нудное и чреватое 
ошибками. В CLR все символм представленм 16-разрчднмми кодами К)никода, 
а строки состоит толдко из 16-разриднмх символов К)никода. Зто намного упро- 
гцает работу с символами и строками в период вмполнении. 

Однако порои текст требуетси записатБ в фаил или передатБ его по сети. Когда 
текст состоит главннш образом из символов англииского извжа, записк и передача 
16-разриднБ1х значении становитсл незффективнои, посколвку половина баитов 
содержит нули. Позтому разумнее сначала закодироватг> (encode) 1 6 -разридш. 1 е 
символБ 1 в более компактнвп! массив баитов, что6б1 потом декодироватв (decode) 
его в массив 16 -разрмдш> 1 х значении. 

Кодирование текста помогает также управлнемвш приложенинм работатн со 
строками, созданнБши в системах, не поддерживагогцих К)никод. Так, чтобв! создатБ 
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текстовми фаил, предназначеннми длн нпонскои версии Windows 95, нужно сохра- 
нитв текст в КЗникоде, исполБзун код Shift-JIS (кодован страница 932). Аналогично 
с помшцмо кода Shift-JIS можно прочитатБ в CLR текстовми фаил, созданнми 
в нпонскои версии Windows 95. 

Кодирование обмчно вмполннетсл перед отправкои строки в фаил или сетевои 
потокспомшцвк)типов System. 10. BinaryWniten и System.IO.StreamWriten. Де- 
кодирование обмчно вмполниетсл при чтении из фаила или сетевого потока с по- 
мшцмо типов System . 10. BinaryReader и System . 10. StreamReader. Если кодировка 
нвно не указана, все зти типм по умолчаншо исполБзугот код UTF-8 (UTF означает 
Unicode Transformation Format). B зтом разделе операции чтенгш и записи строк 
в потоки рассмотренм более подробно. 

К счастБГО, в FCL естБ типбц упрогцагогцие операции кодировангш и декодиро- 
вангш. К наиболее часто исполвзуемБш кодировкам относлт UTF-16 и UTF-8. 

□ UTF-16 кодирует каждвш 16-разриднБш символ в 2 баита. При зтом символб 1 
остаготсн, как бкши, и сжатгш даннБ1х не происходит — скоростБ процесса отлич- 
наи. Часто код UTF-16 назкшагот егце К)никод-кодировкои (Unicode encoding). 
Заметвте также, что, исполБзул UTF-16, можно вбшолнитб преобразование 
из прнмого поридка баитов (big endian) в обратнвп! (little endian), и наоборот. 

□ UTF-8 кодирует некоторкге символб1 одним баитом, другие — двумн баитами, тре- 
тби — тремн, а некоторБге — четБгрБмн. Символб1 со значенгшми ниже 0x0080, 
которБт в основном исполвзуготсл в англоизБшнБ 1 х странах, сжимаготсн в один 
баит. Символб 1 между 0x0080 и 0x07FF, хорошо подходигцие дли европеиских 
II среднеазиатских нзбгков, преобразуготсн в 2 баита. Символбц начинан с 0x0800 
II вБпне, предназначеннБге длн нзбгков Восточнои Азии, преобразуготсл в 3 баита. 
И наконец, napi>i символов-заместителеи (surrogate character pairs) записвша- 
iotcii в 4 баита. UTF-8 — весвма популнрнаи система кодировангш, однако она 
уступает UTF-16, если нужно кодироватв много символов со значешшми от 
0x0800 II вБпне. 

Хотл длл болБшинства случаев подходлт кодировки UTF-16 и UTF-8, FCL под- 
держивает и менее популирнвге кодировки. 

□ UTF-32 кодирует все символбг в 4 баита. Зта кодировка исполвзуетсл длн созда- 
Н 1 ш простого алгоритма прохода символов, в котором не требуетси разбиратвси 
с символами, состолгцими из переменного числа баитов. В частности, UTF-32 
упрогцает работу с символами-заместителими, так как каждвш символ состоит 
ровно из 4 баит. Испо, что UTF-32 незффективна с точки зренил зкономии 
памлти, позтому она редко исполБзуетсл длн сохраненгш или передачи строк 
в фаил или по сети, а обвгано примениетсл внутри программ. Стоит также за- 
метитв, что UTF-32 можно задеиствоватБ д./ш преобразовангш прнмого порндка 
следовангш баитов в обратнвпг, и наоборот. 

□ UTF-7 о 6 бшно исполБзуетсл в старвгх системах, где под символ отводитсл 7 раз- 
рлдов. Зтои кодировки следует избегатв, посколбку обкгано она приводит не 
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к сжати io, а к раздуваниго даннмх. Комитет Unicode Consortium настолтелБно 
рекомендует отказатћси от применешш UTF-7. 

□ ASCII кодирует 16-разрнднме символм в ASCII -символм; то естБ лгобои 16- 
разрнднми символ со значением менБше 0x0080 переводитси в одиночнми баит. 
Символм со значением болг>ше 0x007F не поддаготсн зтому преобразованиго, и зна- 
чение символа терлетсл. Длл строк, состоигцих из символов в ASCII -диапазоне (от 
0x00 до 0x7F), зта кодировка сжимает даннме наполовину, причем оченв бмстро 
(посколБку старшии баит просто отбрасмваетсл). Даннми код не годитсл длл 
символов вне ASCII -диапазона, так как терлготсн значенин символов. 

Наконец, FCL позволнет кодироватБ 16-разриднме символм в произволБнуго 
кодовуго страницу. Как и в случае с ASCII, зто преобразование может привести к по- 
тере значении символов, не отображаеммх в заданнои кодовои странице. Исполб- 
зуите кодировки UTF-16 и UTF-8 во всех случалх, когда не имеете дело со стармми 
фаилами и приложенинми, в котормх применена какаи-либо инан кодировка. 

Чтобм вмполнитб кодирование или декодирование набора символов, сначала 
надо получитБ зкземплир класса, производного от System . Text . Encoding. Аб- 
страктнми базовми класс Encoding имеет несколБКО статических своиств, каждое 
из котормх возврагцает зкземплнр класса, производного от Encoding. 

Пример кодировангш и декодировангш символов с исполБЗОванием кодировки 
UTF-8: 

using System; 
using System.Text; 

public static class Program { 
public static void Main() { 

// Кодируемап строка 
String s = "Hi there."; 

// Получаем očbeKTj производнми от Encoding, которуи "умеет" BbinonHflTb 
// кодирование и декодирование с исполизованием UTF-8 
Encoding encodingUTFS = Encoding.UTF8; 

// Вмполнлем кодирование строки в массив баитов 
Byte[] encodedBytes = encodingUTF8.GetBytes(s); 

// Показуваем значение закодированнмх баитов 
Console.WriteLine("Encoded bytes: " + 

BitConverter.ToString(encodedBytes) ) ; 

// Вмполнлем декодирование массива баитов обратно в строку 
String decodedString = encodingUTFS.GetString(encodedBytes) ; 

// Показуваем декодированну 10 строку 

Console.WriteLine("Decoded string: " + decodedString) ; 

I 
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Вот резулБтат вБшолненин зтои программБП 

Encoded bytes : 48-69-20-74-68-65-72-65-2Е 
Decoded string: Hi there. 

Помимо UTF8, у класса Encoding естБ и другие статические своиства: Unicode, 
BigEndianUnicode, UTF32, UTF7, ASCII и Def ault. Последнее возврашает обвект, 
которвпг вБшолнпет кодирование и декодирование с учетом кодовои страницБ1 
полБЗОвателл, заданнои с iiomoiiu.io утилитБ 1 Regional and Language Options (Лзбш 
и региоиалБНБ1е стандартБ1) панели управленил (см. описание \\1п32-фупк'ц11 и 
GetACP). Однако своиство Def ault применнтв не рекомендуетсл, потому что по- 
ведение приложенгш будет зависетв от настроики машинБ1, то естБ при изменении 
кодовои таблицБц предлагаемои по умолчаншо, или вБшолнении приложенгш на 
другои машине приложение поведет себи иначе. 

Нарлду с перечисленнБ 1 ми своиствами, у Encoding еств статическии метод 
GetEncoding, позволшогции указатв кодовуго страницу (в виде числа или строки). 
Метод GetEncoding возврагцает обвект, вбшолнлгогции кодирование/декодирование, 
исполвзул заданнуго кодовуго страницу. Например, можно ввгзватв GetEncoding 
с параметром "Shift-DIS" или 932. 

Пргг первом запросе обг.екта кодировангш своиство класса Encoding (или его 
метод GetEncoding) создает и возврагцает обвект длл требуемои кодировки. При 
последугогцих запросах такого же обвекта будет возврагцатвсл уже имегогциисл 
обг.ект; то еств пргг очередном запросе новбги обг.скг не создаетсн. Благодарн зтому 
сокрагцаетсл число обвектов и снижаетсл нагрузка на кучу. 

Кроме статических своиств и метода GetEncoding класса Encoding, длн созда- 
нгш зкземплнра класса кодировангш можно задеиствоватв классБг System.Text. 
UnicodeEncoding, System.Text.UTF8Encoding,System.Text.UTF32Encoding,System. 
Text .UTF7Encoding или System.Text .ASCIIEncoding. Толбко помните, что в зтих 
случанх в управлнемои куче попвнтсн новвге обвектБг, что неминуемо отрицателБно 
скажетсл на производителБности. 

У классов UnicodeEncoding,UTFSEncoding,UTF32Encoding и UTF7Encoding еств 
несколБКО конструкторов, дагогцггх дополнителвнБге возможностб в плане управле- 
нгш процессом кодированин и маркерами последователтости баптов (Byte Order 
Mark, ВОМ). Перввге три класса также имегот конструкторБг, которБге позволнгот 
заставитв класс генерироватБ исклгочение при декодировании некорректнои по- 
следователвности баитов; зти конструкторвг нужно исполБЗОватв длн обеспеченин 
безопасности приложенин и загцитБг от приема некорректнБгх входнбгх ддннбгх. 

Возможно, пргг работе с BinaryWriter илгг StreamWriter вам прггдетсл нвно соз- 
даватв зкземплирБг зтих классов. У класса ASCIIEncoding лишб один конструктор, 
и позтому возможности управленгш кодированием здесв невелики. Получатв обв- 
ект ASCIIEncoding (точнее, сскглку на него) всегда следует путем запроса своиства 
ASCII класса Encoding. Никогда не создаваите самостолтелвно зкземплир класса 
ASCIIEncoding — при зтом создаготсл дополнителБНБге обвектБг в куче, что отри- 
цателвно сказБгваетсн на производителвности. 
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Вмзвав дли обвекта, производного от Encoding, метод GetBytes, можно преоб- 
разоватБ массив символов в массив баитов. (У зтого метода естБ несколБКО пере- 
груженнБ 1 х версии.) Дли обратного преобразовашш ввиовите метод GetChars или 
более удобнвш GetStning. (Зти методБ 1 также имегот несколкко перегруженнБ 1 х 
версии.) Работа методов GetBytes и GetStning продемонстрирована в приведенном 
ранее примере. 

У всех типов, производшлх от Encoding, еств метод GetByteCount, которБП!, не 
вбшолннн реалБного кодированин, подсчитвшает количество баитов, необходимвш 
длл кодировангш данного набора символов. Он может пригодитБСл длл вБвделе- 
нил памнти под массив баитов. Имеетсл также аналогичнвп! метод GetChanCount, 
которБШ возврагцает число подлежагцих декодированшо символов, не вбшолннн 
реалБного декодированин. Зти методБ1 полезнБц когда требуетсн сзкономитб памнтБ 
и многократно исполБЗОватБ массив. 

МетодБ 1 GetByteCount и GetChanCount работагот не так бнштро, посколБку дли 
полЈшенин точного резулктата они должшл анализироватБ массив символов/баитов. 
Если скороств важнее точности, вБтзвшаите GetMaxByteCount или GetMaxChanCount — 
оба метода принимагот целое число, в котором задаетсн число символов или баитов 
соответственно, и возврагцагот максималвно возможнбш размер массива. 

КаждБ 1 и обвект, производнБш от Encoding, имеет набор открБ 1 ТБ 1 х неизменне- 
mhix своиств, дагогцих более подробнуго информациго о кодировании. Подробнее 
см. описание зтих своиств в документации на .NET Framework SDK. 

4 to 6 bi продемонстрироватБ своиства и их назначение, и написал программу, 
в KOTopoii зти своиства вБГОвшаготсц длн разнБ1х вариантов кодировангш: 

using System; 
using System.Text; 

public static class Program { 
public static void Main() { 

foreach (Encodinglnfo ei in Encoding.GetEncodings()) { 

Encoding e = ei.GetEncoding(); 

Console.WriteLine("{l}{0}" + 

"\tCodePage={2}, WindowsCodePage={3}{@}" + 

"\tWebName={4}, HeaderName={5}, BodyName={6}{0}" + 

"\tIsBrowserDisplay={7}, IsBrowserSave={8}{0}" + 

"\tIsMailNewsDisplay={9}, IsMailNewsSave={10}{0}", 

Environment.NewLine, 

e.EncodingName, e.CodePage, e.WindowsCodePage, 
e.WebName, e.HeaderName, e.BodyName, 
e.IsBrowserDisplay, e.IsBrowserSave, 
e.IsMailNewsDisplay, e.IsMailNewsSave); 

} 

} 

} 

Вот резулвтат работБ! зтои программБ! (текст сокрагцен длн зкономии бумаги): 
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IBM EBCDIC (US-Canada) 

CodePage=37j WindowsCodePage=1252 
WebName=IBM037, HeadenName=IBM037, BodyName=IBM@37 
IsBnowsenDisplay=False, IsBnowsenSave=False 
IsMailNewsDisplay=False, IsMailNewsSave=False 

OEM United States 

CodePage=437, WindowsCodePage=1252 
WebName=IBM437, HeadenName=IBM437, BodyName=IBM437 
IsBnowsenDisplay=False, IsBnowsenSave=False 
IsMailNewsDisplay=False, IsMailNewsSave=False 

IBM EBCDIC (Intennational) 

CodePage=50@, WindowsCodePage=1252 
WebName=IBM500, HeadenName=IBM50@, BodyName=IBM500 
IsBnowsenDisplay=False, IsBnowsenSave=False 
IsMailNewsDisplay=False, IsMailNewsSave=False 

Anabic (ASMO 708) 

CodePage=708, WindowsCodePage=1256 

WebName=ASMO-708, HeadenName=ASMO-708, BodyName=ASMO-708 
IsBnowsenDisplay=Tnue, IsBnowsenSave=Tnue 
IsMailNewsDisplay=False, IsMailNewsSave=False 

Unicode 

CodePage=12@0, WindowsCodePage=1200 
WebName=utf-16, HeadenName=utf-16, BodyName=utf-16 
IsBnowsenDisplay=False, IsBnowsenSave=Tnue 
IsMailNewsDisplay=False, IsMailNewsSave=False 

Unicode (Big-Endian) 

CodePage=12@l, WindowsCodePage=1200 

WebName=unicodeFFFE, HeadenName=unicodeFFFE, BodyName=unicodeFFFE 
IsBnowsenDisplay=False, IsBnowsenSave=False 
IsMailNewsDisplay=False, IsMailNewsSave=False 

Westenn Eunopean (DOS) 

CodePage=85@, WindowsCodePage=1252 
WebName=ibm850, HeadenName=ibm85@, BodyName=ibm850 
IsBnowsenDisplay=False, IsBnowsenSave=False 
IsMailNewsDisplay=False, IsMailNewsSave=False 

Unicode (UTF-8) 

CodePage=65@01, WindowsCodePage=120@ 

WebName=utf-8, HeadenName=utf-8, BodyName=utf-8 
IsBnowsenDisplay=Tnue, IsBnowsenSave=Tnue 
IsMailNewsDisplay=Tnue, IsMailNewsSave=Tnue 

Обзор наиболее популнрнмх методов классов, производнмх от Encoding, за- 
вершает табл. 14.3. 
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Таблица 14.3. Методн классов, производннх от Encoding 


Метод 

Описание 

GetPreamble 

Возврагцает массив баитов, показвгвагогцих, что нужно записатБ в по- 
ток перед записг >10 кодированннх баитов. Часто такие баитБг назнвагот 
ВОМ-баитами (byte order mark) или преамбулои (preamble). Когда вн 
приступаете к чтениго из потока, ВОМ-баитћг помогагот автоматиче- 
ски определитв кодировку потока, чтобвг правилвно впгбратБ надлежа- 
гции декодировгцик. В некоторвгх классах, производнвгх от Encoding, 
зтот метод возврагцает массив из 0 баит, что означает отсутствие пре- 
амбулвг. Обвект UTF8Encoding может 6бгтб создан лвно, так чтобвг 
зтот метод возврагцал массив из 3 баит: OxEF, ОхВВ, ОхВЕ Обвект 
UnicodeEncoding может 6бгтб создан лвно, так чтобвг зтот метод воз- 
врагцал массив из двух баит: OxFE, OxFF длл прлмого порлдка следова- 
нил баитов (big endian) или OxFF, OxFE — длл обратного (little endian). 
По умолчаншо исполБзуетсн обратнБги порндок. 

Convert 

Преобразует массив баитов из однои кодировки в другуго. Внутреннлн 
реализацгш зтого статического метода ввгзБгвает метод GetChars длл 
обвекта в исходнои кодировке и передает резулвтат методу GetBytes 
длл обвекта в целевои кодировке. Полученнвги массив баитов возвра- 
гцаетсл ВБгзБгвагогцеи программе 

Equals 

Возврагцает true, если два производнвгх от Encoding обвекта представ- 
ллгот одну кодовуго страницу и одинаковуго преамбулу 

GetHashCode 

Возврагцает кодовуго страницу обвекта кодированил 


Кодирование и декодирование 
потоков символов и баитов 

Представете, что вм читаете закодированнуго в UTF-16 строку с no.vmiubio обт>- 
екта System.Net .Sockets .NetworkStneam. ВесБма веронтно, что баитБ 1 из потока 
поступагот группами разного размера, например сначала придут 5 баит, а затем 7. 
В UTF-16 каждБШ символ состоит из двух баит. Позтому в резулвтате вБИОва метода 
GetString класса Encoding с передачеи первого массива из 5 баит будет возврагцена 
строка, содержагцал толбко два символа. При следугогцем ввгзове GetString из потока 
поступлт следугогцие 7 баит, гг GetString вернет строку, содержагцуго три символа, 
причем все невернвге! 

Причина искаженил даннкгх состоит в том, что ни один из производнБгх от 
Encoding классов не отслеживает состоиние потока между двумн ввгзовами своих 
методов. Если вбг вБгполннете кодирование или декодирование символов и баитов, 
поступагогцих порцггами, то вам придетсл приложитв дополнителБНБге усилил дли 
отслеживании состоннгш между ввгзовами, чтобвг избежатв потери даннБгх. 
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Чтобм вмполнитб декодирование порции даннмх, следует получитБ ссбшку на 
производнБш от Encoding оођскт (как описано в предввдушем разделе) и вБ13ватБ 
его метод GetDecoder. Зтот метод возврагцает ссвшку на вновб созданнБпт обвект 
типа, производного от класса System . Text . Decoder. Класс Decoder, подобно классу 
Encoding, нвлнетсн абстрактнвш базовБш классом. В документации .NET Framework 
SDK вб1 не наидете классов, которме представлигот собои конкретнвге реализации 
класса Decoder, хотл FCL определлет группу производшлх от Decoder классов. 
Все зти классв 1 нвлнготсл внутренними длл FCL, однако метод GetDecoder может 
создатв зкземплнрБ1 зтих классов и вернутв их коду вашего приложенин. 

У всех производнБ 1 Х от Decoder классов сугцествует два метода: GetChars 
и GetCharCount. Естественно, они служат длл декодировании массивов баитов 
и работагот аналогично рассмотреннвш ранее методам GetChars и GetCharCount 
класса Encoding. Когда bki вБ13Б1ваете один из них, он декодирует массив баитов, 
насколвко зто возможно. Если в массиве не хватает баитов длл формированил 
символа, то оставшиеси баитБ 1 сохраннготсл внутри обвекта декодировангш. При 
следугогцем ввгзове одного из зтих методов обвект декодировангш берет оставшиеси 
баитБг и складБшает их с вновб полученнБш массивом баитов — благодарн зтому 
декодирование даннвгх, поступагогцих порцгшми, вБшолшгетсн корректно. 06б6Ктб1 
Decoder весБма удобнБг длн чтенгш баитов из потока. 

Тип, производнБги от Encoding, может служитБ длн кодировангш/декодировангш 
без отслеживангш состоннгш. Однако тип, производнвш от Decoder, можно исполб- 
зоватБ толбко длл декодировангш. Чтобвг вбшолнитб кодирование строки порцгш- 
ми, вместо метода GetDecoder класса Encoding применнетсл метод GetEncoder. 
Он возврагцает вновб созданнБш обвект, производнБш от абстрактного базового 
класса System.Text.Encoder. И опнтб, в документацгш на .NET Framework SDK 
нет описангш классов, представлигогцих собои конкретнуго реализациго класса 
Encoder, хотл в FCL определена группа производнвгх от Encoder классов. Подобно 
классам, производнвш от Decoder, они нвлнготсн внутренними длл FCL, однако 
метод GetEncoder может создаватв зкземшшрБг зтих классов и возврагцатв их коду 
приложенгш. 

Все классБг, производнБге от Encoder, имегот дваметода: GetESytes и GetByteCount. 
При каждом ввгзове обвект, производнвнг от Encoder, отслеживает оставшугосл 
необработаннои информациго, так что даннвге могут кодироватБСи по фрагментам. 

Кодирование и декодирование строк в кодировке Base-64 

В настошцее времи кодировки UTF-16 и UTF-8 весвма популлрнБг. Также вескма 
часто примениетси кодирование последователвностеи баитов в строки в кодиров- 
ке base-64. В FCL еств методБг длл кодированил и декодированил в кодировке 
base-64. Ббгло 6бг логично предположитБ, что длл зтои цели исполБзуетсл тип, 
производнБги от Encoding, но по какои-то причине кодирование и декодирование 
base-64 вБшолниетсл с помогцбго статических методов, предоставллемвгх тггпом 
System.Convert. 
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Чтобм декодироватБ строку в кодировке base-64 в массив баитов, ввшовите 
статическии метод FromBase64Stning или FromBase64CharArray класса Convert. 
Длл декодировантш массива баитов в строку base-64 служит статическии метод 
ToBase64String или ToBase64CharArray класса Convert. Пример исполБЗОвании 
зтих методов: 

using System; 

public static class Program { 
public static void Main() { 

// Получаем набор из 10 баит, сгенерированнмх случаинмм образом 
Byte[] bytes = new Byte[10]; 
new Random().NextBytes(bytes); 

// Отображаем баитн 

Console.WriteLine(BitConverter.ToString(bytes)); 

// Декодируем баитн в строку в кодировке base-64 и вмводим зту строку 
String s = Convert.ToBase64String(bytes); 

Console.WriteLine(s); 

// Кодируем строку в кодировке base-64 обратно в баитм и вмводим их 
bytes = Convert . FromBase64String(s) ; 

Console.WriteLine(BitConverter.ToString(bytes) ) ; 

} 


После компилнции зтого кода и запуска вБшолннемого модулн получим следуго- 
гцие строки (ваш резулћтат может отличатБСн от моего, посколбку баитБ1 полученБ1 
случаинБш образом): 

ЗВ-В9-27-40-59-35-86-54 -5F-F1 
07knQFklhlRf8Q== 

ЗВ-В9-27-40-59-35-86-54 -5F-F1 


За1ди1деннне строки 

Часто обвектБ1 String применнгот длн храненин конфиденциалБНБ1х даннБ1Х, таких 
как пароли или информацин кредитнои картБт К сожаленшо, обвектБ 1 String хра- 
ннт массив символов в памлти, и если разрешитв вБшолнение небезопасного или 
неуправлиемого кода, он может просмотретв адресное пространство кода, наити 
строку с конфиденциалБнои информациеи и исполБЗОватБ ее в своих неблаговид- 
нб 1 х целлх. Даже если обвект String сугцествует недолго и становитси добвгчеи 
уборгцика мусора, CLR может не сразу задеиствоватв ранее заннтуго зтим обвектом 
памнтБ (особенно если речн идет об обвектах String предБгдугцих версии), оставлнн 
символбг обвекта в памлти, где они могут статв добБшеи злоумБгшленника. Кроме 
того, посколБку строки нвлнготсл неизмениемБгми, при манипулиции ими старнге 
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версии «виснт» в памнти, в резулБтате разнћге версии строки остаготсн в различнБ 1 х 
областлх памнти. 

В некоторБ 1 х государственнБ 1 Х учреждениих деиствугот строгие требованил 
безопасности, гарантиругогцие определеннвш уровенБ загцитБк Длн решенгш таких 
задач специалистБГ Microsoft добавили в FCL безопаснвш строковБпг класс System . 
Secunity . SecureString. При создангш обвекта SecureString его код вБгделнет блок 
неуправлнемои памнти, которап содержит массив символов. Уборгцику мусора об 
зтои неуправлиемои памнти ничего не известно. 

Символбг строки шифруготсл длл загцитБг конфиденциалБнои информации от 
лгобого потенциалБно опасного или неуправлнемого кода. Длл дописБгвангш в конец 
строки, вставки, удаленгш или заменвг отделБНБгх символов в загцигценнои строке 
служат соответственно методвг AppendChar, InsertAt, RemoveAt и SetAt. При вБгзове 
лгобого из зтих методов код метода расшифроввшает символбг, вБшолннет операциго 
и затем обратно шифрует строку. Зто означает, что символбг находлтсн в незашифро- 
ванном состоннгш в теченгге оченв короткого периода времени. Зто также означает, 
что СИМВОЛБ1 строки модифицируготсп в том же месте, где хранитси, но скороств 
операции все равно конечна, так что прибегатв к ним желателкно пореже. 

Класс SecureString реализует интерфеис IDisposable, служагцгш длл надежного 
уничтоженил конфиденциалБнои информации, хранимои в строке. Когда при- 
ложениго болвше не нужно хранитБ конфиденциалБнуго строковуго информациго, 
достаточно ввгзватБ метод Dispose типа SecureString или исполБЗОватБ зкземплнр 
SecureString в конструкции using. Внутреншш реализацгш Dispose обнулнет со- 
держимое буфера памнти, чтобвг предотвратитв доступ постороннего кода, и толбко 
после зтого буфер освобождаетсл. Обвект SecureString содержит внутреннии 
обвект класса, производного от SafeBuffer, в которомхранитсн сама строка. Класс 
SafeBuffer наследует от класса CriticalFinalizerObject (см. главу 21), что га- 
рантирует вбгзов метода Finalize попавшего в распорнжение уборгцика мусора 
обвекта SecureString, обнуление строки и последугогцее освобождение буфера. 
В отличие от обвекта String, при уничтоженгш обвекта SecureString символбг 
зашифрованнои строки в памнти не остаготсл. 

Теперв, когда вбг знаете, как создаватк и изменнтБ обвект SecureString, можно 
поговоритБ о его исполБЗОвании. К сожалениго, в последнеи версии FCL поддерж- 
ка класса SecureString ограничена — вернее, методов, принимагогцих параметр 
SecureString, оченв немного. В версии 4 инфраструктурБг .NET Framework пере- 
датБ SecureString в качестве паролн можно: 

□ при работе с криптографическим проваидером (Cryptographic Service Provider, 

CSP) см. класс System.Security.Cryptography.CspParameters; 

□ при создании, импорте или зкспорте сертификата в формате Х.509 см. классвг 

System . Security . Cryptography . X509Certificates.X509Certificate и System. 

Security.Cryptography.XB09Certificates.X509Certificate2; 

□ при запуске нового процесса под определеннои учетнои записвго полБЗОвателл см. 

классБг System.Diagnostics . Process и System.Diagnostics.ProcessStartlnfo; 
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□ при организации нового сеанса записи журнала собмтии см. класс System. 
Diagnostics . Eventing . Reader . EventLogSession; 

□ при исполБЗОвании злемента управленин System . Windows . Controls. PasswordBox 
см. класс своиства SecurePassword. 

Наконец, вм можете создаватБ собственнБ1е методБц принимагогцие в качестве 
аргументаобвект SecureString. В методе надо задеиствоватв обвект SecureString 
длл созданил буфера неуправлнемои памнти, храннгцего расшифрованнвге символбг, 
до исполБЗОвангш зтого буфера в методе. Чтобвг сократитв до минимума временное 
<<окно» доступа к конфиденциалБНБш даннБгм, ваш код должен обрагцатвсн к рас- 
шифрованнои строке минималвно возможное времл. После исполБЗОвангш строки 
следует как можно скорее обнулитв буфер и освободитБ его. Никогда не размегцаите 
содержимое SecureString в типе String — в зтом случае незашифрованнан строка 
находитсл в куче и не обнуллетсл, пока памитв не будет задеиствована повторно 
после уборки мусора. Класс SecureString не переопределлет метод ToString спе- 
циалБно — зто нужно длн предотврагценгш раскрвгтгш конфиденциалвнБгх даннБгх 
(что может произоити при преобразовании их в String). 

Следугогции пример демонстрирует инициализациго и исполБЗОвание Secure- 
String (при компилиции нужно указатв параметр /unsafe компилитора С#): 

using System; 

using System.Security; 

using System.Runtime.InteropServices; 

public static class Program { 
public static void Main() { 

using (SecureString ss = new SecureString()) { 

Console.Write("Please enter password: "); 
while (true) { 

ConsoleKeyInfo cki = Console.ReadKey(true); 
if (cki.Key == ConsoleKey.Enter) break; 

// ПрисоединитБ символм паролн в конец SecureString 
ss . AppendChar(cki.KeyChar); 

Console.Write("*"); 

} 

Console.WriteLine(); 

// Паролц введенЈ отобразим его длн демонстрационнмх целеи 
DisplaySecureString(ss) ; 

} 

// После 'using' SecureString обрабатмваетсл методом Disposed, 

// позтому никаких конфиденциалцних даннмх в памлти нет 

} 

// Зтот метод небезопасен, потому что обрашаетсл к неуправллемои памлти 
private unsafe static void DisplaySecureString(SecureString ss) { 

Char* pc = null; 
try { 

// Дешифрование SecureString в буфер неуправллемои памлти 


продолжение # 
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рс = (Char*) Marshal . SecureStringToCoTaskMemUnicode(ss) ; 

// Доступ к буферу неуправллемои памптиЈ 
// которми хранит дешифрованнув версик) SecureString 
for ( Int32 index = 0; pc[index] != 0; index++) 

Console.Write(pc[index]); 

} 

finally { 

// Обеспечиваем обнуление и освобождение буфера неуправллемои памлти, 

// которши хранит расшифрованнме символш SecureString 
if (рс != null) 

Marshal.ZeroFreeCoTaskMemUnicode((IntPtr) pc); 

} 

} 

} 

Класс System. Runtime. InteropServices .Marshal предоставлнет 5 методов, 
которме служат длн расшифровки символов SecureString в буфер неуправлнемои 
памнти. Всеметодм, заисклвзчениемаргумента SecureString, статическиеи возвра- 
гцагот IntPtr. У каждого метода естБ свлзаннБш метод, которБп} нужно обнзателБно 
ББ13БшатБ длл обнуленин и освобожденин внутреннего буфера. В табл. 14.4 при- 
веденБ 1 методБ 1 класса System . Runtime . InteropServices . Marshal, исполБзуемБге 
длн расшифровки SecureString в буфер неуправлнемои памнти, а также свнзаннвге 
методв! дли обнулении и освобожденгш буфера. 


Таблица 14.4. Методн класса Marshal дла работн с заидииденнБ 1 ми строками 


Метод расшифровки SecureString 
в буфер 

Метод обнуленив и освобожденив буфера 

SecureStringToBSTR 

ZeroFreeBSTR 

SecureStringToCoTaskMemAnsi 

ZeroFreeCoTaskMemAnsi 

SecureStringToCoTaskMemUnicode 

ZeroFreeCoTaskMemUnicode 

SecureStringToGlobalAllocAnsi 

ZeroFreeGlobalAllocAnsi 

SecureStringToGlobalAllocUnicode 

ZeroFreeGlobalAllocUnicode 




Глава 15 . ПеречислимБ1е тигњ1 
и битовше флаги 


Перечислимме типм и битовме флаги поддерживаготсн в Windows долгие годм, 
позтому и уверен, что многие из вас уже знакомв1 с их применением. Но по- 
настонгцему обЂектно-ориентированнмми перечислимме типм и битовме флаги 
становнтсн в обгцеизмковои исполннгогцеи среде (CLR) и библиотеке классов .NET 
Framework (FCL). ЗдесБ у них понвлнготси интереснме возможности, которме, по- 
лагаго, многим разработчикам пока неизвестнм. Менн приитно удивило, насколБКО 
благодари зтим новшествам, о котормх, собственно, и идет разговор в зтои главе, 
можно облегчитБ разработку приложении. 


Перечислимне типм 

Перечислимим (enumerated type) назБгвагот тип, в котором описан набор пар, со- 
стонгцих ггз символбнбгх имен и значении. Далее прггведен тип Color, определнгогцгги 
совокупноств идентификаторов, каждвги ггз которБгх обозначает определеннБги цвет: 

internal enum Color { 

White, // Присваиваетсп значение 0 
Red, // Присваиваетсв значение 1 
Green, // Присваиваетсв значение 2 
Blue, // Присваиваетсв значение 3 
Orange // Присваиваетсв значение 4 

} 


Конечно, в программе можно вместо White написатв 0, вместо Green — 1 и т. д. 
Однако перечислимБш тип все-таки лучше жестко заданнвгх в исходном коде чис- 
ловбгх значении по краинеи мере по двум причинам. 

□ Программу, где исполвзуготсл перечислимБге типбг, прогце написатБ и понитб, 
а у разработчггков возникает менвше проблем с ее сопровождением. Символб- 
ное n м 'А перечислимого типа проходит через весп код, и занималсБ то однои, то 
другои частБго программБг, программист не обизан помнитб значение каждого 
<<зашитого» в коде значенин (что White равен 0, а 0 означает White). Если же 
числовое значенгге символа почему-либо изменгглосв, то нужно толбко пере- 
компилироватБ исходнбги код, не изменнн в нем нгг букввг. Кроме того, работан 
с ггнструментами документированин гг другими утилитами, такггми как отладчик, 
программист видит осмвгсленнвге символБНБге имена, а не цифрБг. 
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□ Перечислимме типм подвергаготсн строгои проверке типов. Например, компилн- 
тор сообгцит об ошибке, если в качестве значентш н попмтагосв передатБ методу 
тип Color .Orange (оранжевми цвет), когда метод ожидает перечислимми тип 
Fruit (фрукт). 

В CLR перечислимме типм — зто не просто идентификаторм, с котормми имеет 
дело компилнтор. Перечислимме типм играгот важнуго ролг> в системе типов, на них 
возлагаетсн решение очсш> серБезнмх задач, просто неммслиммх длн перечислиммх 
типов в других средах (например, в неуправлиемом нзмке С++). 

Каждми перечислимми тип напрнмуго наследует от типа System. Enum, произ- 
водного от System.ValueType, атот, в свого очередБ, — от System.Object. Иззтого 
следует, что перечислимБге типбг относлтсн к значимкш типам (см. главу 5) и могут 
вБгступатБ как в неупакованнои, так и в упакованнои формах. Однако в отличие 
от других значимБгх типов, у перечислимого типа не может 6 бгтб методов, своиств 
и собвпии. Впрочем, как вбг увидите в конце даннои главБц наличие метода у пере- 
числимого типа можно имитироватБ при помогци механизма методов расширенил 
(extension methods). 

При компилиции перечислимого типа компилитор C# преврагцает каждвпз 
идентификатор в константное поле типа. Например, предБвдугцее перечисление 
Color компилнтор видит примерно так: 

internal struct Color : System.Enum { 

// Далее перечислени открмтме константт, 

// определпкицие символннме имена и значенин 
public const Color White = (Color) в; 
public const Color Red = (Color) 1; 
public const Color Green = (Color) 2; 
public const Color Blue = (Color) 3; 
public const Color Orange = (Color) 4; 

// Далее находитсл открнтое поле зкземплнра со значением переменнои Color 
// Код с прлмои ссмлкои на зтот зкземпллр невозможен 
public Int32 value _; 

} 

Однако компилитор C# не будет обрабатвшатв такои код, потому что он не 
разрешает определлтБ типм, производнБге от специалБного типа System . Enum. Зто 
псевдоопределение всего лишб демонстрирует внутреннгого сутв происходпгцего. 
В обгцем-то, перечислимБш тип — зто обБшнан структура, внутри которои описан 
набор константнБгх полеи и одно зкземплпрное поле. КонстантнБге полн попадагот 
в метаданнБге сборки, откуда их можно извлечБ с помогцбго механизма отраженгш. 
Зто означает, что в период вБшолненгш можно получитБ все идентификаторБг и их 
значенгш, свнзаннБге перечислимБш типом, а также преобразоватБ строковБп! иден- 
тификатор в зквивалентное ему числовое значение. Зти операции предоставлешл 
базоввгм типом System.Enum, которБш предлагает статические и зкземплирнБге 
методБг, вБшолннгогцие специалБНБге операции над зкземплнрами перечислимБгх 
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типов, избавлнн вас от необходимости исполБЗОватБ отражение. Мм поговорим 
о них подробно чутБ позже. 

ВНИМАНИЕ 

OnncaHHbie перечислимнм типом символн лвлл 10 тсл константами. Встречал в коде 
символическое имл перечислимого типа, компиллтор заменлет его числовв 1 м зна- 
чением. В резулитате определчклцал перечислимми тип сборка можетоказатисч не- 
нужнои во времл вмполненил. Но если в коде присутствуетсшлка не наопределеннв 1 е 
перечислимв 1 м типом символические имена, а на сам тип, присутствие сборки на 
стадии вмполненил будетоблзателђнв 1 м. То есљ возникает проблема версии, свлзан- 
нал стем, что символм перечислимого типалвллкггсл константами, а незначенилми, 
предназначеннв!ми толико длл чтенил. Зта тема подробно освеш,ена в главе 7. 


К примеру, длз типа System . Enum сугцествует статическии метод GetUnderlyingType, 
а дли типа System . Туре — зкземплнрнБпт метод GetEnumUnderlyingType: 

public static Туре GetUnderlyingType(Type епитТуре); // Определен 

// в типе System.Enum 

public Туре GetEnumUndenlyingType( ); // Определен в типе System.Type 

Оба зтих метода возврагцагот базовми тип, исполБзуемБш дли храненил значенин 
перечислимого типа. В основе лгобого перечисленгш лежит один из основнбгх типов, 
например byte, sbyte, short, ushort, int (именно он исполвзуетсн в C# по умол- 
чаниго), uint, long и ulong. Все зти примитивнвге тшш C# имегот аналоги в FCL. 
Однако компилнтор C# пропустит толбко примитивпми тип; задание базового 
класса FCL (например, Int32) приведет к сообшениго об ошибке (ошибка CS1008: 
ожидаетси тип byte, sbyte, short, ushort, int, uint, long или ulong): 

error CS1008: Туре byte, sbyte, short, ushort, int, uint, long, or ulong expected 

Вот как должно вбшллдстб на C# обБнвление перечисленин, в основе которого 
лежит тип byte (System . Byte): 

internal enum Color : byte { 

White, 

Red, 

Green, 

Blue, 

Orange 

} 

Если перечисление Color определено подобнмм образом, метод 
GetUnderlyingType вернет следугогции резулвтат: 

// Зта строка вмводит "System.Byte" 

Console . WriteLine(Enum.GetUnderlyingType(typeof(Color))); 

Компилитор C# считает перечислимБ 1 е типб 1 примитивнБши, позтому длн 
операции с их зкземплнрами примениготсн уже знакомнге нам операторБ! (==, ! =, 
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<, >, <=, >=, +, -, л , &, |, ~, ++ и —). Все они применннзтсл к полго value _зкземплнра 

перечислении, а компиллтор C# допускает приведение зкземплиров одного пере- 
числимого типа к другому. Также поддерживаетсл нвное и нелвное приведение 
к числовому типу. 

Имегогцииси зкземплнр перечислимого типа можно свизатћ со строковмм пред- 
ставлением — длн зтого следует вмзватБ ToStning, унаследованнми от System . Enum: 

Color с = Color.Blue; 

Console.WriteLine(c); // "Blue" (Обшии формат) 

Console.WriteLine(c.ToString()); // "Blue" (Обшии формат) 

Console.WriteLine(c.ToString("G")); // "Blue" (Обшии формат) 

Console.WriteLine(c.ToString("D")); // "3" (Деслтичнми формат) 

Console.WriteLine(c.ToString("X")); // "03" (Шестнадцатеричнии формат) 


ПРИМЕЧАНИЕ 

При работе с шестнадцатеричгљ1м форматом метод ToString всегда возврашает 
nponncHbie 6yKBbi. Количество B03BpameHHbix цифр зависит от типа, лежаш,его 
в основе перечисленив. Длл типов byte/sbyte — зто две цифри1, длл типов short/ 
ushort — seTbipe, длл типов int/uint — BOceMb, а длп типов long/ulong — снова две. 
При необходимости добавлнкзтсл ведуидие нули. 


Помимо метода ToStning тип System . Enum предлагает статическии метод Fonmat, 
служагции дли форматировангш значенин перечислимого типа: 

public static String Format(Type епитТуре д Object value, String format); 

B обгцем случае метод ToStning требует менмпего обвема кода и прогце в вмзове. 
С другои сторонм, методу Fonmat можно передатг. числовое значение в качестве 
параметра value, даже если у вас отсутствует зкземплнр перечисленгш. Например, 
зтот код вмведет строку "Blue": 

// В резулцтате вмводитсл строка "Blue" 

Console . WriteLine(Enum.Format(typeof(Color) , 3, "G")); 


ПРИМЕЧАНИЕ 

Можно očtsBHTb перечисление, различни1е идентификатори1 которого имекзт оди- 
наковое числовое значение. В процессе преобразовании числового значенил в сим- 
вол посредством обш,его форматированил методи1 типа вернут один из символов, 
правда, неизвестно какои. Если соответствил не обнаруживаетсл, возвраидаетсл 
строка с числови 1 м значением. 


Статическии метод GetValues типа System. Enum и метод GetEnumValues зкзем- 
плира System . Туре создагот массив, злементами которого становитсн символБнме 
имена перечисленгш. И каждми злемент содержит соответствугогцее числовое 


значение: 


Перечислимие типм 407 


public static Аггау GetValues(Type епитТуре); // Определен в System.Enum 
public Аггау GetEnumValues(); // Определен в System.Type 

Зтот метод вместе с методом ToStning позволнет вмвести все идентификаторм 
и числовме значенип перечисленин: 

Color[] colors = (Color[]) Enum.GetValues(typeof(Color) ); 

Console.WriteLine("Number of symbols defined: " + colors.Length); 

Console. WriteLine("Value\tSymbol\n-\t-"); 

foreach (Color c in colors) { 

// Вв 1 водим каждми идентификатор в деслтичном и обцем форматах 
Console.WriteLine( "{0, 5:D}\t{0:G}", с); 

} 


Резулкгат вмполнешш зтого кода вмглпдит так: 

Number of symbols defined: 5 
Value Symbol 


0 White 

1 Red 

2 Green 

3 Blue 

4 Orange 

Лично мне методм GetValues и GetEnumVal не нравитси, потому что они воз- 
врагцагот обвект Ar гау, которми приходитсн преобразовмватБ к соответствугогцему 
типу массива. Л всегда определиго собственнми метод: 

public static TEnum[] GetEnumValues<TEnum>() where TEnum : struct { 
return (TEnum[])Enum.GetValues(typeof(TEnum)); 

} 

Обобгценнвш метод GetEnumValues улучшает безопасностБ типов на стадии 
компилнции и упрошает первуго строку кода в предмдушем примере до следуго- 
шего вида: 

Color[] colors = GetEnumValues<Color>( ); 

Мм рассмотрели некоторме интереснме операции, применимме к перечислиммм 
типам. Полагаго, что показмватБ символбнбш имена злементов полћзователБСКого 
интерфеиса (раскрБшагогцихсл списков, полеи со списком и т. п.) чагце всего вбг 
будете с помогцбго метода Т oStning с исполБЗОванием обгцего формата (если вбшо- 
димбго строки не требугот локализации, которап не поддерживаетсн перечислимвши 
типами). Помимо метода GetValues, типб 1 System . Enum и System . Туре предостав- 
лигот егце два метода длп полученгш символических имен перечислимвгх типов: 

// Возвратает строковое представление числового значенил 

public static String GetName(Type епитТуре, Object value); // Определен 

// в System.Enum 

public String GetEnumName(Object value); // Определен в System.Type 
// Возвратает массив строк: по однои на каждое 

продолжение & 
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// cMMBonbHoe имл из перечисленил 

public static String[] GetNames(Type епитТуре); // Определен в System.Enum 
public String[] GetEnumNames(); // Определен в System.Type 

Мм рассмотрели несколБКО методов, позволнкпцих наити символическое ими 
(или идентификатор) перечислимого типа. Однако нужен егце и метод определенин 
значенин, соответствугогцего идентификатору, например, вводимому полБЗОвателем 
в текстовое поле. Преобразование идентификатора в зкземплнр перечислимого типа 
легко реализуетси статическими методами Parse и TryParse типа Enum: 

public static Object Parse(Type епитТуре., String value); 

public static Object Parse(Type епитТуре, String value, Boolean ignoreCase); 
public static Boolean TryParse<TEnum>(String value, 
out TEnum result) where TEnum: struct; 
public static Boolean TryParse<TEnum>(String value, 

Boolean ignoreCase, out TEnum result) 
where TEnum : struct; 

Пример исполБЗОванин даннмх методов: 

// Так как Orange определен как 4, 'с' присваиваетсл значение 4 
Color с = (Color) Enum.Parse(typeof(Color) , "orange", true); 

// Так как Brown не определен, генерируетсл исклтчение ArgumentException 
с = (Color) Enum.Parse(typeof(Color) , "Brown", false); 

// Создаетсл зкземпллр перечисленил Color со значением 1 
Enum.TryParse<Color>("l" , false, out с); 

// Создаетсл зкземпллр перечисленил Color со значение 23 
Enum.TryParse<Color>("23" , false, out с); 

Наконец, рассмотрим статическии метод IsDefined типа Enum и метод IsEnum- 
Def ined типа Туре: 

public static Boolean IsDefined(Type епитТуре, Object value); // Определен 

// в System.Enum 

public Boolean IsEnumDefined(Object value); // Определен в System.Type 

C их помогцвго определлетсл допустимостБ числового значенин длл данного 
перечисленин: 

// Вуводит "True", так как в перечислении Color 

// идентификатор Red определен как 1 

Console . WriteLine(Enum.IsDefined(typeof(Color) , 1)); 

// Вуводит "True", так как в перечислении Color 
// идентификатор White определен как 0 

Console . WriteLine(Enum.IsDefined(typeof(Color) , "White")); 

// Вуводит "False", так как вмполнлетсл проверка с учетом регистра 
Console . WriteLine(Enum.IsDefined(typeof(Color) , "white")); 

// Вуводит "False", так как в перечислении Color 

// отсутствует идентификатор со значением 10 

Console . WriteLine(Enum.IsDefined(typeof(Color), (Byte)10)); 

Метод IsDef ined часто исполБзуетси дли проверки параметров. Например: 

public void SetColor(Color с) { 

if (! Enum.IsDefined(typeof(Color) , c)) { 
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thnow(new ArgumentOutOfRangeException("c ", c, "Invalid Color value.")); 

} 

// Вадатв цветЈ как White, Red, Green, Blue или Orange 

} 

Без подобнои проверки не обоитисв, потому что полБЗОвателБ вполне может 
вмзватБ метод SetColor вот таким способом: 

SetColor((Color) 547); 

Так как соответствие числу 547 в перечислении отсутствует, метод SetColor 
генерирует исклгочение ArgumentOutOf RangeException с информациеи о том, какои 
параметр недопустим и почему. 

ВНИМАНИЕ 

При всем удобстве метода IsDefined применатв его следует с осторожносљк). Во- 
nepBbix, он всегда витолнлет поиск с учетом регистра, во-вторнх, работает краине 
медленно, так как в нем исполвзуетсв отражение. Самостолтелвно написав код про- 
верки возможних значении, Bbi повмсите производителвноств своего приложенил. 
Кроме того, метод работает толвко длз перечислимв 1 х типов, определенннх в тои 
сборке, из которои он Bbi3biBaeTce. Например, пусљ перечисление Color определено 
в однои сборке, а метод SetColor — в другои. При вмзове методом SetColor метода 
IsDefined все будет работањ, если цвет имеет значение White, Red, Green, Blue или 
Orange. Однако если в будуш,ем Mbi добавим в перечисление Color цвет Purple, метод 
SetColor начнет исполвзоватв неизвестное ему значение, а резулвтат его pa6oTbi 
станет непредсказуеме 1 м. 


Напоследок упоминем набор статических методов ToObject типа System . Enum, 
преобразукдцих зкземплирм типа Byte, SByte, Intl6, UIntl6, Int32, UInt32, Int64 
или UInt64 в зкземплирм перечислимого типа. 

Перечислимме типм всегда применнкзт в сочетании с другим типом. Обмчно их 
исполБзугот в качестве параметров методов или возврагцаеммх типов, своиств или 
полеи. Часто возникает вопрос, где лучше определнтБ перечислимћш тип: внутри 
или на уровне того типа, которому он требуетси. В FCL bbi увидите, что обвгано 
перечислимБпт тип определиетсн на уровне класса, которвш он исполвзуетси. Зто 
делаетсн просто дли того, что 6 б 1 сократитБ обвем набираемого разработчиком кода. 
Позтому при отсутствии возможнб 1 х конфликтов имен лучше определитв пере- 
числимБ1е типб 1 на одном уровне с основнбш классом. 


Битовме флаги 

ПрограммистБ 1 часто работагот с наборами 6 итовб 1 х флагов. Метод GetAttributes 
типа System . 10. File возврашдет зкземплир типа FileAttributes. Тип FileAttri- 
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butes нвлиетсн зкземплиром перечислимого типа, основанного на типе Int32, где 
каждми разрад соответствует какому-то атрибуту фаила. В FCL тип FileAttributes 
описан следугогцим образом: 

[Flags, Serializable] 
public enum FileAttributes { 

ReadOnly = 0x0001, 

Hidden = 0x0002, 

System = 0x0004, 

Directory = 0x0010, 

Archive = 0x0020, 

Device = 0x0040, 

Normal = 0x0080, 

Тетрогагу = 0x0100, 

SparseFile = 0x0200, 

ReparsePoint = 0x0400, 

Compressed = 0x0800, 

Offline = 0x1000, 

NotContentIndexed = 0x2000, 

Encrypted = 0x4000 

} 


Следугогции фрагмент провернет, ивллетсл ли фаил скрнтнм: 

String file = Assembly.GetEntryAssembly() . Location; 

FileAttributes attributes = File.GetAttributes(file); 

Console.WriteLine("Is {0} hidden? {1}", file, ( 
attributes & FileAttributes.Hidden) != 0); 

ПРИМЕЧАНИЕ 

B классе Enum имеетсл метод HasFlag, определнемми следукнцим образом: 

public Boolean HasFlag(Enum flag); 

C его noMOuibio можно nepenncaTb внзов метода ConsoleWriteLine: 

Console.WriteLine("Is {0} hidden? {1}", file, 
attributes.HasFlag(FileAttributes.Hidden)); 

Однако н не рекомендукз исполвзоватв метод HasFlag. Дело в том, что он принимает 
параметрм типа Enum, азначит, передаваемме ему значенил должни 6biTbynaK0BaHbi, 
что требует дополнителБнмх затрат памнти. 


А зтот пример демонстрирует, как изменитг> фаилу атрибутм «толбко дли чте- 
нгш» и «скрмтми»: 

File.SetAttributes(file, FileAttributes . ReadOnly | FileAttributes . Hidden) ; 

Из описанин типа FileAttnibutes видно, что, как правило, при создании набора 
комбинируеммх друг с другом битовмх флагов исполћзугот перечислимме типм. 
Однако песмотрм на внешнгого схожестг., перечислимБге типбг семантически отли- 
чаготси от битовБгх флагов. Если в первом случае мбг имеем отделБНБге числовбш 
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значенин, то во втором приходитсл иметБ дело с набором флагов, одни из котормх 
установленм, а другие нет. 

Определнн перечислимми тип, предназначеннми длн идентификации битовмх 
флагов, каждому идентификатору следует лвно присвоитБ числовое значение. 
Обмчно в соответствукчцем идентификатору значении установлен липњ один бит. 
Также часто приходитсн видетБ идентификатор None, значение которого определено 
как 0. Егце можно определитБ идентификаторБц представлигогцие часто исполб- 
зуемБге комбинации (см. приведеннБпг далее символ ReadWnite). Настолтелвно 
рекомендуетсл применнтБ к перечислимому типу специализированнБш атрибут 
типа System . FlagsAttnibute: 

[Flags] // КомпилАтор C# допускает значение "Flags" или "FlagsAttribute" 
internal enum Actions { 

None = 0 
Read = 0x0001, 

Write = 0x0002, 

Readl/Jrite = Actions.Read | Actions.Write, 

Delete = 0x0004, 

Query = 0x0008, 

Sync = 0x0010 

} 

Длн работБ1 c перечислимБш типом Actions можно исполБЗОватБ все методБц 
описаннБге в предввдугцем разделе. Хотн иногда возникает необходимоств изменитБ 
поведение рнда функции. К примеру, рассмотрим код: 

Actions actions = Actions.Read | Actions.Delete; // 0x0005 
Console.Writel_ine(actions.ToStringQ); // "Read, Delete" 

Метод ToStning пБ 1 таетсл преобразоватБ числовое значение в его символбнбш 
зквивалент. Но у числового значенгш 0x0005 нет символбного зквивалента. Од- 
нако обнаружив у типа Actions атрибут [Flags], метод ToStning рассматривает 
числовое значение уже как набор битоввгх флагов. Так как битвг 0x0001 и 0x0005 
установленБг, метод ToStning формирует строку "Read, Delete". Если в описании 
TnnaActions убратватрибут [Flags], методвернет строку "5". 

В предвгдугцем разделе мбг рассмотрели метод ToStning и привели три способа 
форматировангш вбгходнои строки: "G" (обгции), "D" (деснтичнБш) и "X" (шест- 
надцатеричнБш). Форматирун зкземплнр перечислимого типа с исполБЗОванием 
обгцего формата, метод сначала определлет наличие атрибута [ Flags ]. Если атрибут 
не указан, отвгскиваетси и возврагцаетсл идентификатор, соответствугогции данно- 
му числовому значениго. Обнаружив же дашњш атрибут, ToStning деиствует по 
следугогцему алгоритму: 

1. Получает набор числовбгх значении, определеннБгх в перечисленгш, и сортирует 
их в нисходнгцем поридке. 

2. Длн каждого значенгш ввшолннетсн операцгш конђгонкцгш (AND) с зкземплнром 
перечисленгш. В случае равенства резулвтата числовому значениго свизаннаи 
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с ним строка добавлнетсл в итоговуго строку, соответствукпцие же битм считагот- 
сн учтеннмми и сбрасмваготсн. Операции повториетсл до завершенин проверки 
всех числовмх значении или до сброса все битов зкземплиров перечисленин. 

3. Если после проверки всех числовмх значении зкземплир перечисленил все 
егце не равен нулго, зто означает наличие несброшеннмх битов, котормм не со- 
поставленм идентификаторм. В зтом случае метод возврагцает исходное число 
зкземплнра перечислентш в виде строки. 

4. Если исходное значение зкземплнра перечисленгш не равно нулго, метод воз- 
врагцает набор символов, разделеннмх запнтои. 

5. Если исходнмм значением зкземплнра перечисленил бмл нолг>, а в перечис- 
лимом типе естБ идентификатор с таким значением, метод возврагцает зтот 
идентификатор. 

6. Если алгоритм доходит до данного шага, возврагцаетсл 0. 

Что 6 б 1 получитБ правилБнуго резулБтиругогцуго строку, тип Actions можно 
определитБ и без атрибута [Flags], Длл зтого достаточно указатн формат "F": 

// [Flags] // Tenepb зто просто комментарии 
internal enum Actions { 

None = 0 
Read = 0x0001, 

Write = 0x0002, 

Readl/drite = Actions.Read | Actions.Ulrite, 

Delete = 0x0004, 

Query = 0x0008, 

Sync = 0x0010 

} 

Actions actions = Actions.Read | Actions.Delete; // 0x0005 
Console.WriteLine(actions.ToString("F")); // "Read, Delete" 

Если числовое значение содержит бит, которому не соответствует какои-либо 
идентификатор, в возврагцаемои строке окажетси толбко деслтичное число, равное 
исходному значениго, и ни одного идентификатора. 

Заметвте: идентификаторБц которше вбг определнете в перечислимом типе, не 
обизанБг 6 б 1 тб степенБГО двоики. Е1апример, в типе Actions можно описатв иденти- 
фикатор с именем All, имегогции значение 0x001F. Резулнтатом форматировангш 
зкземплнра типа Actions со значением 0x001F станет строка "All". Других иден- 
тификаторов в строке не будет. 

Пока мбг говорили лишб о преобразовании числовбгх значении в строку флагов. 
Однако вб 1 можете также получитБ числовое значение строки, содержагцеи разде- 
леннвге заплтои идентификаторБг, восполБЗОвавшисБ статическим методом Panse 
типа Enum или методом TnyPanse. Рассмотрим зто на примере: 

// Так как Query определпетсп как 8, 'а' получает началБное значение 8 
Actions а = (Actions) Enum.Parse(typeof(Actions) , "Query", true); 
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Console.WriteLine(a.ToString()); // "Query" 

// Так как у нас определенн и Query> и Readj 'а' получает 

// началвное значение 9 

Enum.TryParse<Actions>("Query, Read"j false, out a); 

Console.WriteLine(a.ToString()); // "Readj Query" 

// Создаем зкземпллр перечисленил Actions enum co значением 28 

a = (Actions) Enum.Parse(typeof(Actions)j "28"j false); 

Console.WriteLine(a.ToString()); // "Deletej Query, Sync" 

При вмзове методов Parse и TryParse вмполннкзтсн следугошие деиствин: 

1. Удалиготсл все пробелм в начале и конце строки. 

2. Если первмм символом в строке нвллетсл цифра, знак <<плгос» (+) или знак 
«минус» (-), строка считаетсл числом и возврапдаетсн зкземплнр перечисленип, 
числовое значение которого совпадает с числом, полученнмм в резулвгате пре- 
образованин строки. 

3. Переданнан строка разбиваетсл на разделеннБ 1 е запнтћши лексемБр и у каждои 
лексемБ1 удаллготси все пробелБ1 в начале и конце. 

4. Ввшолннетсл поиск каждои строки лексемБ 1 среди идентификаторов перечисле- 
нил. Если символ наити не удаетсл, метод Parse генерирует исклгочение System . 
ArgumentException, а метод TryParse возврашает значение false. При обнару- 
жении символа его числовое значение путем дизбгонкции (OR) присосдипиетси 
к резулБтиругогцему значениго, и метод переходит к анализу следугогцего символа. 

5. После обнаруженгш и проверки всех лексем резулвтат возврагцаетсн программе. 
Никогда не следует применнтв метод IsDefined с перечислимБгми типами би- 

товбгх флагов. Зто не будет работатв по двум причинам: 

□ Переданнуго ему строку метод не разбивает на отделвнБге лексемБг, а шцет целиком, 
вместе с загштБши. Однако в перечислении не может присутствоватв идентифи- 
катор, содержагции заплтБге, а значит, резулнтат поиска всегда будет нулеввш. 

□ После передачи ему числового значенгш метод игцет всего один символ перечис- 
лимого типа, значение которого совпадает с переданнвш числом. Длл битовБгх 
флагов веронтноств полученгш положителБного резулкгата при таком сравнении 
ничтожно мала, и обвгчно метод возврагцает значение false. 


Добавление методов 
к перечислиммм типам 


В начале главвг уже упоминалосв, что определитв метод как частк перечислимого 
типа невозможно. Зто ограничение удручало менн в течение многих лет, так как 
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то и дело возникали ситуации, когда требовалосБ снабдитБ перечислимБге типбг 
методами. К счастБкз, теперБ его можно обоити при помогци относителБно нового 
длл C# механизма методов расширенил (extension method), которвш подробно 
рассматриваетси в главе 8. 

Длл добавленгш методов к перечислимому типу FileAttnibutes нужно опреде- 
литб статическии класс с методами расширентш. Делаетсл зто следугогцим обра- 
зом: 

internal static class FileAttributesExtensionMethods { 
public static Boolean IsSet( 

this FileAttributes flags, FileAttributes flagToTest) { 
if (flagToTest == 0) 
throw new ArgumentOutOfRangeException( 

"flagToTest", "Value must not be 0"); 
return (flags & flagToTest) == flagToTest; 

} 

public static Boolean IsClear( 

this FileAttributes flags, FileAttributes flagToTest) { 
if (flagToTest == 0) 
throw new ArgumentOutOfRangeException( 

"flagToTest", "Value must not be 0"); 
return !IsSet(flags, flagToTest); 

} 

public static Boolean AnyFlagsSet( 

this FileAttributes flags, FileAttributes testFlags) { 
return ((flags & testFlags) != 0); 

} 

public static FileAttributes Set( 

this FileAttributes flags, FileAttributes setFlags) { 
return flags | setFlags; 

} 

public static FileAttributes Clear( 

this FileAttributes flags, FileAttributes clearFlags) { 
return flags & ~clearFlags; 

} 

public static void ForEach(this FileAttributes flags, 

Action<FileAttributes> processFlag) { 

if (processFlag == null) throw new ArgumentNullException("processFlag"); 
for (UInt32 bit = 1; bit != 0; bit <<= 1) { 

UInt32 temp = ((UInt32)flags) & bit; 

if (temp != 0) processFlag((FileAttributes)temp); 

} 

} 
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Следукмции фрагмент демонстрирует вмзов одного из таких методов. Как легко 
заметитБ, он вб1гллдит так, как вБ 1 глндел бм вбиов методов перечислимого типа: 

FileAttributes fa = FileAttributes . System; 
fa = fa.Set(FileAttributes.ReadOnly); 
fa = fa.Clear(FileAttributes.System); 
fa.ForEach(f => Console.WriteLine(f)); 



Глава 16. МассивБ! 


Массив представлнет собои механизм, позволанмции рассматриватћ набор злементов 
как единуго коллекцшо. Обшеизмкован исполннкжцан среда Microsoft .NET (CLR) 
поддерживает одномерние (single-dimension), многомерние (multidimension) и нере- 
гулнрние (jagged) массивм. Базовмм длл всех массивов нвлнетсн абстрактнми класс 
System. Аггау, производнмиот System.Object. Значит, массивм всегдаотнослтсн 
к ссмлочному типу и размегцаготсн в управлнемои куче, а переменнан в приложении 
содержит не злементм массива, а ссмлку на массив. Рассмотрим пример: 

Int32[] mylntegers; // Обилвление ссмлки на массив 

mylntegers = new Int32[100]; // Создание массива типа Int32 из 100 злементов 

В первои строке обЂнвлнетси переменнан mylntegers, которан будет ссмлатЂСи 
наодномернми массив злементов типа Int32. Вначале eii присваиваетсл значение 
null, так как памитЂ под массив пока не вмделена. Во второи строке вмделнетси 
памнтЂ под 100 значении типа Int32; и всем им присваиваетсн началЂное значение 0. 
ПосколЂку массивм относитси к ссмлочнмм типам, блок памити длн храненин 100 
неупакованнмх зкземплнров типа Int32 вмделиетси в управлиемои куче. Вообгце 
говори, помимо злементов массива в зтом блоке размегцаетсл указателЂ на обвект- 
тип, индекс блока синхронизации, а также некоторме дополнителБнме членм. Адрес 
зтого блока памити заноситсн в переменнуго mylntegers. 

Можно также создатБ массивБг с злементами ссбшочного типа: 

Control[] myControls; // Обкпвление сшлки на массив 

myControls = new Control[50]; // Создание массива из 50 сшлок 

// на переменнув Control 

Переменнан myControls из первои строки может указвгватв на одномернБш 
массив ссБглок на злементБг Control. Вначале eii присваиваетси значение null, 
ведв памнтБ под массив пока не ввгделена. Во второи строке вБвделиетсл памнтБ 
под 50 ссбшок на Control, и все они инициализируготси значением null. Посколб- 
ку Control относитси к ссБ1лочнБ1м типам, массив формируетсл путем созданин 
ссБглок, а не каких-либо реалБНБгх обЂектов. ВозврагценнБиг адрес блока памити 
заноситси в переменнуго myControls. 

На рис. 16.1 показано, как вбггллднт массивБг значимого и ссбглочного типов 
в управлиемои куче. 

На зтом рисунке показан массив Controls после ввшолнешш следугогцих ин- 
струкции: 

myControls [1] = new Button(); 
myControls [2] = new TextBox(); 

myControls[3] = myControls[2]; // Два злемента ссмлагатсл на один обБект 
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myControls[46] 
myControls[48] 
myControls[49] 


new DataGrid(); 
new ComboBox(); 
new Button(); 


mylntegers 


Рис. 16.1. Массивм значимого и ссвточного типов в управлнемои куче 

Согласно обгцензмковои спецификации (CLS), нумерацин злементов в массиве 
должна начинатБСн с нулн. Толбко в зтом случае методм, написаннме на С#, смогут 
передатБ ссмлку на созданнми массив коду, написанному на другом нзмке, скажем, 
на Microsoft Visual Basic .NET. Кроме того, поско./њку массивм с началћнмм нуле- 
вмм индексом получили очеш, бо.ткшос распространение, специалистм Microsoft 
постаралисБ оптимизироватБ их работу. Тем не менее инме вариантм индексации 
массивов в CLR допускаготси, хотн их испо./њзовапие не рекомендуетси. В случанх 
когда п|)оиз,1!Одител biiocT i, и межЂлзмкован совместимостЂ программ не имегот 
болЂшого значенгш, можно исполЂЗОватЂ массивм, началЂнми индекс котормх от- 
личен от 0. Мм подробно рассмотрим их чутБ позже. 

На рисунке видно, что в массиве присутствует некаи дополнителБнаи инфор- 
мации. Зто сведенин о размерности массива, нижних границах всех его измерении 
(почти всегда 0) и количестве злементов в каждом измерении. ЗдесБ же указвшаетсл 
тип злементов массива. МетодБ 1 длл получении зтих даннБ 1 х будут рассмотренБ 1 
далее в зтои главе. 

Пока что нам известен толбко процесс создангш одномернкгх массивов. По воз- 
можности нужно ограничиватвси одномернБши массивами с нулеввш началБНБш 
индексом, KOTO|)i,ie назкшагот иногда SZ -массивами, или векторами. ВекторБг обе- 
спечивагот наилучшуго производителвностБ, посколбку длл операции с ними ис- 
полБзуготсн командБг промежуточного нзБгка (Intermediate Language, IL), например 
newann, ldelem, ldelema, ldlen и stelem. Впрочем, если у вас еств такое желание, 
можно применнтБ и многомернБге массивБк Вот как они создаготси: 

// Создание двухмерного массива типа Doubles 
Double[,] myDoubles = new Double[10, 20]; 
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// Создание трехмерного массива сшлок на строки 
Stringfjj] myStrings = new String[5, 3, 10]; 

CLR поддерживает также нерегуЈшрние (jagged) массивм — то естБ «массивБ 1 
массивов». ПроизводителћностБ одномернБ 1 х нерегулнрнБ 1 х массивов с нулевћш 
началБНБш индексом такал же, как у о 6 бмнб 1 х векторов. Однако обрагцение к зле- 
менту нерегулнрного массива означает обрагцение к двум или болвше массивам 
одновременно. Вот пример массива многоуголБников, где каждвш многоуголБник 
состоит из массива зкземплиров типа Point: 

// Создание одномерного массива из массивов типа Point 
Point[][] myPolygons = new Point[3][]; 

// myPolygons[0] ссћшаетсл на массив из 10 зкземплпров типа Point 
myPolygons [0] = new Point[10]; 

// myPolygons[1] сснлаетсп на массив из 20 зкземплпров типа Point 
myPolygons[l] = new Point[20]; 

// myPolygons[2] сстлаетсл на массив из 30 зкземплпров типа Point 
myPolygons[2] = new Point[30]; 

// BbiBOfl точек первого многоуголБника 

for (Int32 х = 0; х < myPolygons[0].Length; x++) 

Console.WriteLine(myPolygons[0][x]); 


ПРИМЕЧАНИЕ 

CLR проверлет корректностБ индексов. To естБ если у вас имеетсл массив, состол- 
1ции из 100 злементов с индексами от 0 до 99, попмтка обратитБСл к его злементу по 
индексу-5 или 100 породит исклкзчение System.lndex.OutOfRange. Доступ к памати 
за пределами массива нарушает безопасносш типов и создает бреиљ в заидите, не- 
допустимуго длл верифицированного CLR -кода. Проверка индекса обмчно не влилет 
на производителБностБ, так как компиллтор вмполнлет ее всего один раз перед 
началом цикла, а не на каждои итерации. Впрочем, если bw считаете, что проверка 
индексов критична длл скорости вв1полнении вашеи nporpaMMbi, исполизуите длл 
доступа к массиву небезопаснв 1 и код. Зта процедура рассмотрена в разделе «Про- 
изводителБносњ доступа к массиву» даннои главм. 


Инициализацил злементов массива 

В предБгдугцем разделе рассмотрена процедура создашш злементов массива 
и присвоенин им началБНБ1х значении. Синтаксис C# позволиет совместитв зти 
операции: 

String[] names = new String[] { "Aidan", "Grant" }; 

Набор разделеннБ1х запнтои символов в фигурнвш скобках назБшаетси иници- 
ализатором массива (аггау initializer). Сложностб каждого символа может 6 bitb 
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произволБнои, а в случае многомерного массива инициализатор может оказатБСн 
вложеннБш. В показанном примере фигурирукзт всего два простБ1х вБфаженгш 
типа String. 

Если в методе обБнвлиетсл локалвнан переменнан длн работнг с инициализи- 
рованнБш массивом, длл упрогценин кода можно восполБЗОватБСл переменнои 
ненвного типа var: 

// ИсполБЗование локалинои переменнои ненвного типа: 
var names = new String[] { "Aidan", "Grant" 

B резулвтате компиллтор делает вбгвод о том, что локалБнаи переменнан names 
относитсл к типу String [ ], так как именно к зтому типу принадлежит вБгражение, 
расположенное справа от оператора присваивангш (=). Исполвзун ненвнуго типиза- 
циго массивов С#, вбг поручаете компилитору определитБ тип злементов массива. 
Обратите внимание на отсутствие спецификации типа между операторами new и [ ] 
в следугогцем фрагменте кода: 

// Задание типа массива с помоцвк) локалинои переменнои ненвного типа: 
var names = new[] { "Aidan", "Grant", null }; 

Компшштор определлет тип ввгражении, исполБзуемБгх длл ггнггцггалггзацгггг 
злементов массива, гг по резулвтатам вБгбирает базовБш класс, которБги лучше 
всего описвгвает все злементвг. В показанном примере компшштор обнаруживает 
два злемента типа String и значенгге null. Но так как последнее может 6 бгтб не- 
нвно преобразовано в лгобои ссбглочнбги тип, внгбор делаетсл в полвзу созданггн 
гг ггнггцггалггзацгггг массива ссбглок тггпа String. 

Егце прггмер: 

// Ошибочное задание типа массива с noMombio локалБнои 

// переменнои нелвного типа 

var names = new[] { "Aidan", "Grant", 123 }; 

Ha такогг код компгглнтор реагггрует сообгценггем (ошггбка CS0826: подходнгцего 
тггпа дли ненвно заданного массггва не обнаружено): 

error CS0826: No best type found for implicitly-typed аггау 

Дело в том, что обгцггм базоввгм типом длн двух строк гг значенгш типа Int32 
нвлнетсл тггп Ob ј ect. Длн компгглнтора зто означает необходимоств создатБ массггв 
ссбглок типа Object, а затем упаковатн значенгге тггпа Int32 гг заставггтБ последнгги 
злемент массива ссБглатвсп на резулнтат упаковкгг, ггмегогцгги значенгге 123. Раз- 
работчикгг сочли, что задача упаковкгг злементов массива прггводит к слггшком 
вбгсокггм затратам, чтобкг компггллтор мог вбгполннтб ее ненвно, позтому в такои 
ситуацгггг просто вбгводитсл сообгцение об ошггбке. 

В качестве сггнтаксического бонуса можно указатв возможностб вот такои ггнгг- 
цггалггзацгггг массива: 

String[] names = { "Aidan", "Grant" }; 

Обратите внггмангге, что справа от оператора прггсваггвангш располагаготсл толбко 
началБНБге значенгш злементов массггва. Нгг оператора new, нгг тггпа, нгг квадратнвгх 
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скобок там нет. Зтот синтаксис удобен, но к сожаленшо, в зтом случае компилнтор 
не разрешает исполБЗОватБ локалБНБ1е переменнБ1е ненвного типа: 

// Ошибочное исполизование локалБнои переменнои 
var names = { "Aidan", "Grant" }; 

ПопБ 1 тка компилнции такои строчки приведет к понвленшо двух сообвдении: 

error CS0820: Cannot initialize an implicitly-typed local variable with 
an аггау initializer 

error CS0622: Can only use аггау initializer expressions to assign аггау types. 

Тгу using a new expression instead 

Первое говорит o том, что локалвнои переменнои неивного типа невозможно 
присвоитв началБное значение при помогци инициализатора массива, а второе 
информирует, что даннвш инициализатор примениетсн толбко длл назначенип 
типов массивам и рекомендует вам восполвзоватБСп оператором new. В принципе, 
компилнтор вполне способен вбшолнитб все зти деиствин самостолтелвно, но раз- 
работчики решили, что зто — слишком сложнаи задача. ВедБ пришлосБ 6 б 1 опреде- 
лнтб тип массива, создаватв его при помогци оператора new, присваиватБ злементам 
началБНБШ значенгш, а кроме того, определлтБ тип локалпнои переменнои. 

Напоследок хотелосп 6ni рассмотретБ процедуру непвного заданин типа массива 
в случае анонимнБ1х типов и локалвнБ1х переменнБ1х ненвного типа. (06 анонимнБ1х 
типах см. главу 10.) 

Рассмотрим следугогции код: 

// Применение переменннх и массивов ненвно заданного типа, 

// а также анонимного типа: 

var kids = new[] {new { Name="Aidan" }, new { Name="Grant" }}; 

// Пример примененин (c другои локалвнои переменнои нелвно заданного типа): 
foreach (var kid in kids) 

Console.WriteLine(kid.Name); 

B зтом примере длп присваивангш началвнБ 1 х значении злементам массива ис- 
полБзуготсн два ввфаженин, каждое из которБ1х представлнет собои анонимнвш тип 
(ведБ после оператора new ни в одном из случаев не фигурирует имп типа). Благо- 
дари идентичнои структуре зтих вБфажении (поле Name типа String) компшштор 
относит оба обљекта к одному типу. Теперп mki можем восполБЗОватБСн возможно- 
стбго неивного заданин типа массива (когда между оператором new и квадратнвши 
скобками отсутствует имп типа). В резулвтате компилнтор самостонтелБно опре- 
делит тип, сконструирует массив и инициализирует его злементБ1 как ссбшки на 
два зкземплпра одного и того же анонимного типа. В итоге ссвшка на зтот обвект 
присваиваетсн локалвнои переменнои kids, тип которои определит компиллтор. 

Затем толбко что создашњш и инициализированнБпг массив исполвзуетсл в ци- 
кле foreach, в котором фигурирует и переменнаи kid непвного типа. Вот резулвтат 
вБшолненгш такого кода: 

Aidan 

Grant 
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Приведение типов в массивах 

В CLR длл массивов с злементами ссмлочного типа допустимо приведение. В рамках 
решенин зтои задачи оба типа массивов должнм иметБ одинаковуго размерностБ; кро- 
ме того, должно иметБ место ненвное или нвное преобразование из типа злементов 
исходного массива в целевои тип. CLR не поддерживает преобразование массивов 
с злементами значимБ 1 х типов в другие типб 1 . Впрочем, данное ограничение можно 
обоити при помогци метода Ar гау. Сору, KOTopniii создает hobkih массив и заполннет 
его злементами. Вот пример приведении типа в массиве: 

// Создание двухмерного массива FileStream 
FileStream[ ,] fs2dim = new FileStream[5, 10]j 

// Нелвное приведение к массиву типа Object 
Object[,] o2dim = fs2dim; 

// Невозможно приведение двухмерного массива к одномерному 

// Ошибка компилнции CS0030: невозможно преобразоватц тип ' object [*,*]' 

// в 'System.IO.Stream[] ' 

Stream[] sldim = (Stream[]) o2dim; 

// Нвное приведение к двухмерному массиву Stream 
Stream[,] s2dim = (Streamf,]) o2dim; 

// Лвное приведение к двухмерному массиву String 
// Компилируетсв, но во времл вшполненил 
// возникает исклтчение InvalidCastException 
String[,] st2dim = (String[,]) o2dim; 

// Создание одномерного массива Int32 (значимми тип) 

Int32[] ildim = new Int32[5]; 

// Невозможно приведение массива значимого типа 
// Ошибка компиллции CS0030: невозможно преобразоватц 
// тип " int []" в 'objectf]' 

Object[] oldim = (Object[]) ildim; 

// Создание нового массива и приведение злементов к нужному типу 
// при помоши метода Аггау.Сору 

// Создаем массив ссмлок на упакованнше злементн типа Int32 
Object[] obldim = new Object[ildim.Length]; 

Array.Copy(ildim, obldim, ildim.Length); 

Метод Аггау .Сору не просто копирует злементБ1 одного массива в другои. Он 
деиствует как функцил memmove лзБ1ка С, но при зтом правилБно обрабатБ1вает 
перекрБ1ваЈОгциесн области памлти. Он также способен при необходимости преоб- 
разовБ1ватБ злементБ1 массива в процессе их копированин. Метод Сору вБшолннет 
следугогцие деиствин: 

□ Упаковка злементов значимого типа в злементвг ссбглочного типа, например 
копирование Int32[] BObject[]. 



422 Глава 16. MaccnBbi 


□ Распаковка злементов ссмлочного типа в злементм значимого типа, например 
копирование Object []в Int32 [ ]. 

□ Расширение (widening) примитивнмх значиммх типов, например копирование 

Int32[] в Double[], 

□ Понижагогцее приведение в случанх, когда совместимостБ массивов невозможно 
определитБ по их типам. Сгода относитси, к примеру, приведение массива типа 
Object[ ] в массив типа IFormattable[ ]. Если все odneKTbi в массиве Object [ ] 
реализугот интерфеис IFormattable[ ], приведение проидет успешно. 

Вот егце один пример примененгш метода Сору: 

// Определение значимого типа, реализукицего интерфеис 
internal struct MyValueType : IComparable { 
public Int32 CompareTo(Object obj) { 

} 

} 

public static class Program { 
public static void Main() { 

// Создание массива из 100 злементов значимого типа 
MyValueType[] src = new MyValueType[100] ; 

// Создание массива ссмлок IComparable 
IComparable[] dest = new IComparablefsrc.Length]; 

// Присваивание злементам массива IComparable ссилок на упакованнме 
// версии злементов исходного массива 
Array.Copy(src, dest, src.Length); 

} 


Нетрудно догадатБСн, что FCL достаточно часто исполБзует достоинства метода 

Аггау.Сору. 

Бвгвагот ситуации, когда полезно изменитв тип массива, то еств вбшолнитб его 
ковариацит (аггау covariance). Однако следует помнитб, что зта операцгш сказнг- 
ваетси на производителвности. Допустим, вбг написали такои код: 

Stringf] sa = new String[100]; 

Object[] oa = sa; // oa ссмлаетсл на массив злементов типа String 
oa[5] = "leff"; // CLR проверлет принадлежностн oa к типу String; 

// Проверка проходит успешно 

oa[3] = 5; // CLR проверлет принадлежностн оа к типу Int32; 

// Генерируетсл исклшчение ArrayTypeMismatchException 

В зтом коде переменнан оа, тип которои определен как Object [ ], ссБшаетсн на 
массив типа String[ ]. Затем вбг пБгтаетесБ присвоитБ одному из злементов зтого 
массива значение 5, относигцеесл к типу Int32, производному от типа Object. 
Естественно, CLR провернет корректностБ такого присваивашш, то естБ в про- 
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цессе вмполненин контролирует наличие в массиве злементов типа Int32. В дан- 

ном случае такие злементм отсутствугот, что и становитсн причинои исклгоченин 

ArrayTypeMismatchException. 

ПРИМЕЧАНИЕ 

Дла простого копированил части алементов из одного массива в другои имеет CMbica 
ncnoab30BaTb метод BlockCopy класса System.Buffer, которми работаетбмстрее ме- 
тода Аггау.Сору. К сожаленикз, зтот метод поддерживает толико примитивнме Tnnbi 
и не имееттакихже широких возможностеи приведенин, как Аггау.Сору. Параметрм 
типа Int32 вмражак)тсл путем смеш,енил баитов внутри массива, а не при помоиди 
индексов. То ecTb метод BlockCopy подходит длч поразрлдного копированил со- 
вместиммх даннмх из массива одного типа в другои. К примеру, таким способом 
можно скопироваљ массив типа Byte[], содержаидии символм (Оникода, в массив 
типа Char[], Зтот метод частично компенсирует отсутствие возможности считатв 
массив просто блоком памчти произволиного типа. 

Длч надежного копированил набора злементов из одного массива в другои ис- 
полвзуите метод ConstrainedCopy класса System.Array. Он гарантирует, что в случае 
неудачного копированил будет вмдано исклкдчение, но даннме в целевом массиве 
останутсл неповрежденнмми. Зто позволлет исполвзоватв метод ConstrainedCopy 
в области ограниченного вмполненил (Constrained Execution Region, CER). Гарантии, 
которме он дает, обусловленм требованием, чтобм тип злементов исходного массива 
совпадал с типом злементов целевого или бмл производнмм от него. Кроме того, 
метод не поддерживаетупаковку, распаковку или нисходчидее приведение. 


Базовми класс System.Array 

Рассмотрим обЂчвление переменнои массива: 

FileStream[] fsArray; 

ОбЂнвление переменнои массива подобнмм образом приводит к автоматиче- 
скому созданиго типа FileStream[] длл домена приложении. Тип FileStream[] 
нвллетсн производнмм от System.Array и соответственно наследует оттуда все 
методм и своиства. Длн их вмзова служит переменнан f sArray. Зто упротцает ра- 
боту с массивами, ведв в классе System.Array еств множество полезнмх методов 
и своиств, в том числе Clone, СоруТо, GetLength, GetLongLength, GetLowerBound, 
GetUpperBound,Length и Rank. 

Класс System.Array содержит также статические методм длл работм с масси- 
вами, в томчисле AsReadOnly, BinarySearch, Clear, ConstrainedCopy, ConvertAll, 
Сору, Exists,Find, FindAll, Findlndex, FindLast, FindLastIndex,ForEach,IndexOf, 
LastIndexOf, Resize, Reverse, Sort и TrueForAll. B качестве параметра они при- 
нимагот ссмлку на массив. У каждого из зтих методов сугцествует множество пере- 
груженнмх версии. Более того, длл многих из них имеготси обобгценнме перегру- 
женнме версии, обеспечивагогцие контролв типов во времн компилнции и вмсокуго 


424 Глава 16. MaccnBbi 


производителБностБ. Л настолтелБно рекомендуго самостолтелћно почитатћ о них 
в документации на SDK. 


Реализацил интерфеисов lEnumerable, 
ICollection и IList 

Многие методБ 1 работагот с коллекциими, посколкку они обБнвленБ 1 с такими 
параметрами, как интерфеисБ 1 IEnumerable, ICollection и IList. Им можно 
передаватБ и массивБЦ так как зти три необобгценнБ1Х интерфеиса реализованБ1 
в классе System . Аггау. Даннаи реализацин обусловлена тем, что зти интерфеисБ 1 
интерпретиругот лгобои злемент как зкземплнр System.Object. Однако хотелоск 
6 б 1 также, что 6 б 1 класс Sy stem . Ar гау реализовБшал обобгценнБШ зквивалентБ 1 зтих 
интерфеисов, обеспечиван лучшии контролв типов во времн компилнции и повб 1 - 
шеннуго производителБностБ. 

Команда разработчиков CLR решила, что не стоит осугцествлитБ реализациго 
интерфеисов IEnumerable<T>, ICollection<T> и IList<T> классом System.Array, 
так как в зтом случае возникагот проблемБ1 с многомернБ1ми массивами, а также 
с массивами, в которБ 1 х нумерации не начинаетсл с нулл. Ведв определение зтих 
интерфеисов в указанном классе означает необходимоств поддержки массивов 
всех типов. Вместо зтого разработчики пошли на хитроств: при создании одно- 
мерного массива с начинагогцеисл с нулл индексациеи CLR автоматически реа- 
лизует интерфеисБг IEnumerable<T>, ICollection<T> и IList<T> (здесБ Т — тип 
злементов массива), а также три интерфеиса длл всех базоввгх типов массива 
при условии, что оти типБ 1 лвллготсл ссб 1 лочнб 1 ми. Ситуациго иллгострирует 
следугош,аи иерархил. 

Object 

Аггау (необобтеннне IEnumerable, ICollection, IList) 

Object[] (IEnumerable, ICollection, IList of Object) 

String[] (IEnumerable, ICollection, IList of String) 

Stream[] (IEnumerable, ICollection, IList of Stream) 

FileStream[] (IEnumerable, ICollection, IList of FileStream) 

(другие массиви ссилочнмх типов) 


Пример: 

FileStream[] fsArray; 

В зтом случае при создании типа FileStream[] CLR автоматически реали- 
зует в нем интерфеисБ 1 IEnumerable<FileStream>, ICollection<FileStream> 
и IList<FileStream>. Более того, тип FileStream[ ] будет реализовБ 1 ватБ ин- 
терфеисБ 1 базовБ 1 х классов IEnumerable<Stream>, IEnumerable<Object>, 
ICollection<Stream>, ICollection<Object>, IList<Stream> и IList<Object>. 
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Так как все зти интерфеисм реализуготсл средои CLR автоматически, переменнаи 
fsArray может применитБСл во всех случалх исполБЗОванин зтих интерфеисов. 
Например, ее можно передаватБ в методБ 1 с такими прототипами: 

void Ml(IList<FileStream> fsList) { ... } 
void M2(ICollection<Stream> sCollection) { ... } 
void M3(IEnumerable<0bject> oEnumerable) { ... } 

Обратите внимание, что если массив содержит злементБ 1 значимого типа, класс, 
которому он принадлежит, не будет реализовБшатБ интерфеисБ1 базовБ1х классов 
злемента. Например: 

DateTime[] dtArray; // Массив злементов значимого типа 

В данном случае тип DateTime[] будет реализоввшатБ толбко интерфеисБ 1 
IEnumenable<DateTime>, ICollection<DateTime> и IList<DateTime>; версии зтих 
интерфеисов, обшие дли классов System.ValueType или System.Object, реализованБ1 
не будут. А зто значит, что переменнуго dtAr гау нелБЗи передатБ показанному ранее 
методу МЗ в качестве аргумента. Ведв массивБ1 значимБ1х и ссбшочнбш типов рас- 
полагаготси в памнти по-разному (об зтом рассказвшалосБ в начале даннои главв!). 


Передача и возврат массивов 

Передаван массив в метод в качестве аргумента, i:i>i на самом деле передаете ссвшку 
на него. А значит, метод может модифицироватБ злементБ 1 массива. Зтого можно 
избежатв, передав в качестве аргумента копиго массива. Имеите в виду, что метод 
Аггау.Сору вБшолнлет поверхностное (shallow) копирование, и если злементБ 1 
массива относитсн к ссвшочному типу, в новом массиве окажутсн ссбшки на сугце- 
ствугогцие o6'i>einp>i. 

Аналогично, отделБнвго методБ 1 возврагцагот ссБ 1 лку на массив. Если метод 
создает и инициализирует массив, возврагцение такои ссбшки не вБШБшает про- 
блем; если же вб 1 хотите, что 6 б 1 метод возврагцал ссвшку на внутреннии массив, 
ассоциированнБш с полем, то сначала решите, вправе ли вБГОБшагогцап программа 
иметБ доступ к зтому массиву. Как правило, делатв зтого не стоит. Позтому лучше 
пустБ метод создаст массив, ввгоовет метод Аггау. Сору, а затем вернет ссвшку на 
новби! массив. Егце раз напомнго, что даннвп! метод вБшолннет поверхностное 
копирование исходного массива. 

Резулвтатом i:i>i.30i:a метода, возврагцагогцего ссвшку на массив, не содержагции 
злементов, нвлнетсл либо значение null, либо ссвшка на массив с нулеввш числом 
злементов. В такои ситуации Microsoft настонтелвно рекомендует второи вариант, 
посколБку подобнан реализацин упрогцает код. К примеру, даннкш код вБшолннетсн 
правилБно даже при отсутствии злементов, подлежагцих обработке: 

// Пример простого длл пониманил кода 

Appointmentf ] appointments = GetAppointmentsForToday( ); 

продолжение # 
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for (Int32 a = 0; a < appointments.Length; a++) { 

} 

Следуклции фрагмент кода также корректно вмполниетсл при отсутствии зле- 
ментов, но он уже сложнее: 

// Пример более сложного кода 

Appointmentf ] appointments = GetAppointmentsForToday( ); 
if (appointments != null) { 

for (Int32 a = 0, a < appointments.Length; a++) { 

// Вмполнлем деиствил c алементом appointments[a] 

} 

} 

Если вм пишете свои методм так, чтобм они вместо null возврагцали массивм 
с нулевмм числом злементов, полБЗОвателнм будет прогце работатБ с ними. То же 
относитсл к iio.TMM. Если у вашего типа естБ поле, мн.ти lomceca ссмлкои на массив, 
то в него следует помегцатБ ссбшку на массив, даже если в массиве нет ни одного 
злемента. 


MaccHBbi с ненулевои нижнеи границеи 

Как уже упоминалосБ, массивБ 1 с ненулевои нижнеи границеи вполне допустимБг 
СоздаватБ их можно при помогци статического метода Createlnstance типа Агпау. 
Сугцествует несколБКО перегруженнБ1х версии зтого метода, позволнгогцих задатв 
тип злементов, размерноств, нижнгого границу массива, а также количество злемен- 
тов в каждом измерении. Метод вБвделнет памнтв, записБшает заданнБге параметрБ1 
в служебнуго областв вБвделенного блока и возврагцает ссвшку на массив. При на- 
личии двух и более измерении ссвшку, возврагценнуго методом Createlnstance, 
можно привести к типу переменнои ElementType [ ] (здесБ ElementType — имн типа), 
что 6 б 1 упроститБ доступ к алементам массива. Длл доступа к злементам одномернвгх 
массивов полБзуитесв методами GetValue и SetValue класса Агпау. 

Рассмотрим процесс динамического создангш двухмерного массива значении 
типа System.Decimal. Первое измерение составнт годбг с 2005 по 2009 вклгочи- 
телБно, а второе — кварталБ1 с 1 по 4 вклгочителвно. Все злементБ1 обрабатБшаготси 
в цикле. Прописав в коде границБ1 массива в нвном виде, mbi получили 6bi вБшгрвш 
в производителвности, но вместо зтого восполвзуемсл методами GetLowerBound 
и GetUpperBound класса System. Аггау: 

using System; 

public static class DynamicArrays { 
public static void Main() { 

// Требуетсл двухмернии массив [2005..2009][1..4] 

Int32[] lowerBounds = { 2005, 1 }; 
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Int32[] lengths = { 5, 4 }; 

Decimalt,] quanterlyRevenue = (Decimal[j]) 

Amay.CreateInstance(typeof(Decimal), lengths^ lowerBounds); 

Console.WriteLine("{0j4} {1,9} {2,9} {3,9} {4,9}", 

"Year"j "01", "Q2", "Q3", "Q4"); 

Int32 firstYear = quarterlyRevenue.GetLowerBound(0); 

Int32 lastYear = quarterlyRevenue.GetUpperBound(@); 

Int32 firstQuarter = quarterlyRevenue.GetLowerBound(l); 

Int32 lastQuarter = quarterlyRevenue.GetUpperBound(l); 

for (Int32 уеаг = firstYear; уеаг <= lastYear; year++) { 
Console.Write(year + " "); 
for (Int32 quarter = firstQuarter; 
quarter <= lastQuarter; quarter++) { 

Console.Write("{0,9:C} ", quarterlyRevenue[year, quarter]); 

} 

Console.WriteLine(); 

} 

} 

} 


После компилиции и виполнешш зтого кода получаем: 


Year 

Qi 

Q2 

Q3 

Q4 

2005 

$0.00 

$0.00 

$0.00 

$0.00 

2006 

$0.00 

$0.00 

$0.00 

$0.00 

2007 

$0.00 

$0.00 

$0.00 

$0.00 

2008 

$0.00 

$0.00 

$0.00 

$0.00 

2009 

$0.00 

$0.00 

$0.00 

$0.00 


Внутреннлл реализацил массивов 

В CLR поддерживаготсл массивм двух типов: 

□ Одномернме массивм с нулевмм началБнвш индексом. Иногда их назмвагот 
SZ -массивами (от англииского single-dimensional, zero-based), или векторами. 

□ Одномернме и многомернме массивм с неизвестнмм началБнмм индексом. 

Рассмотрим их на примере следугогцего кода (резултат его вмполненгш при- 
водитсл в комментаринх): 

using System; 

public sealed class Program { 
public static void Main() { 

Аггау a; 

// Создание одномерного массива c нулевим 
// началннмм индексом и без злементов 

продолжение & 
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а = new String[0]; 

Console.WniteLine(a.GetType()); // "System.Stning[]" 

// Создание одномерного массива c нулевум 
// началинмм индексом и без злементов 
а = Annay.CneateInstance(typeof(Stning), 
new Int32[] { 0 }, new Int32[] { 0 }); 
Console.WniteLine(a.GetType()); // "System.Stning[]" 

// Создание одномерного массива c началвнмм индексом 1 и без злементов 
а = Annay.CneateInstance(typeof(Stning), 
new Int32[] { 0 }, new Int32[] { 1 }); 
Console.WniteLine(a.GetType()); // "System.Stningf*]" <-- ВНИМАНИЕ ! 

Console.WniteLine(); 

// Создание двухмерного массива c нулевум 
// началчнмм индексом и без злементов 
а = new Stning[0, 0]; 

Console.WniteLine(a.GetType()); // "System.Stningf,]" 

// Создание двухмерного массива с нулевум 
// началчнмм индексом и без злементов 
а = Annay.CneateInstance(typeof(Stning), 
new Int32 [] { 0, 0 }, new Int32[] { 0, 0 }); 
Console.WniteLine(a.GetType()); // "System.Stning[,]" 

// Создание двухмерного массива c началвнмм индексом 1 и без злементов 
а = Annay.CneateInstance(typeof(Stning), 

new Int32[] { 0, 0 }, new Int32[] { 1, 1 }); 
Console.WniteLine(a.GetType()); // "System.Stningf,]" 

} 


Рлдом c каждои инструкциеи Console .WriteLine в виде комментарин пока- 
зан резулмат деиствии. Дли одномернмх массивов с нулевои нижнеи границеи 
зто System . String [ ], если же индексацин начинаетси с единицм, вмводитсл уже 
System.String[*]. Знак * свидетелБСтвует о том, что CLR знает о ненулевои 
нижнеи границе. Так как в C# о6ђнвитб переменнуго типа String [ * ] невозможно, 
синтаксис зтого нзвша запрегцает обрагцение к одномернкш массивам с ненулевои 
нижнеи границеи. Впрочем, обоити зто ограничение можно с помогцбго методов 
GetValue и SetValue класса Аггау, но дополнителБНБ1е затратБ1 на вбгоов метода 
снижагот зффективностБ работБ 1 программБк 

Длн многомернБ1х массивов, независимо от нижнеи границБц отображаетсн один 
и тот же тип: System . String[ , ]. Во времн ввшолненил CLR рассматривает их как 
массивБ1 с ненулевои нижнеи границеи. Логично 6бшо 6 б 1 предположитБ, что имн 
типа будет представлено как System . String [*, *] , но в CLR длл многомернБ1х 
массивов не исполБзуетсл знак *. ВедБ иначе он вбшодилсл 6 б 1 во всех случалх, 
создаваи путаницу. 
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Доступ к злементам одномерного массива с нулевои нижнеи границеи осу- 
гцествлнетсл немного бмстрее, чем доступ к злементам многомернв1х массивов 
или массивов с ненулевои нижнеи границеи. Естб несколгжо причин такому по- 
веденгпо. Во-первмх, специалмгме командм длн работн с одномернмми массивами 
с нулевои нижнеи границеи (newarn, ldelem, ldelema, ldlen и stelem) позволнгот 
JIT -компиллтору генерироватБ оптимизированнБш код. При зтом предполагает- 
си, что nepBbifi индекс равен нулго, то ести при доступе к злементам отсутствует 
необходимостБ вбиислнтб смегцение. Кроме того, в обгцем случае компилитор 
умеет вбшоситб код проверки границ за пределБ1 цикла. К примеру, рассмотрим 
следукнции код: 
using System; 

public static class Program { 
public static void Main() { 

Int32[] a = new Int32[5]; 

for(Int32 index = 0; index < a.Length; index++) { 

// Какие-то деиствид c злементом a[index] 

} 

} 

} 

Обратите внимание на вбгоов своиства Length в проверочном ВБфажении цикла 
for. Фактически при зтом вБИБшаетсн метод, но JIT -компилнтор «знает», что Length 
нвлнетсл своиством класса Ar гау, позтому создает код, в котором метод вБГОБшаетсн 
всего один раз, а полученнБш резулБтат сохраннетсл в промежуточнои переменнои. 
Именно ее значение провернетсл на каждои итерации цикла. В резулБтате такои 
код работает оченк 6biCTpo. НекоторБге разработчики недооценивагот возможности 
JIT -компилитора и пишут «умнБ1и код», пБ 1 талсБ помочб его работе. Однако такие 
попб1тки практически всегда приводнт к снижениго производителБности, а также 
делагот готовуго программу непоннтнои и неудобнои длн редактированин. Позтому 
пустБ своиство Length вБИБшаетсн автоматически. 

Кроме того, JIT -компилитор «знает», что цикл обрагцаетсл к злементам массива 
с нулевои нижнеи границеи, указБшан Length -1. Позтому он в процессе вБшолне- 
нии генерирует код, проверигогции, все ли злементБ1 находитсл в границах массива. 
А именно, провернетсл условие: 

(0 >= a.GetLowerBound(0)) && ((Length - 1) <= а .GetUpperBound(0) ) 

Проверка осугцествлиетсл до начала цикла. В случае положителБного резулБ- 
тата компиллтор не создает в теле цикла кода, провернгогцего, не вБпнел ли индекс 
злемента за границБ1 диапазона. Именно за счет зтого обеспечиваетсл вБгсокаи 
производителБностБ доступа к массиву. 

К сожалениго, обрагцение к злементам многомерного массива или массива с не- 
нулевои нижнеи границеи происходит намного медленнеи. ВедБ в зтих случалх код 
проверки индекса не вбшоситсн за пределБ 1 цикла и проверка осугцествлиетсл на 
каждои итерацгш. Кроме того, компилнтор добавлнет код, вБшитагогции из текугцего 
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индекса нижнгого границу массива. Зто также замедлнет работу программм даже 
в случае многомернмх масснвов с нулевои нижнеи границеи. Если вм серБезно оза- 
боченБ1 проблемои производителБности, имеет СМБ1СЛ исполБЗОватБ нерегулирнБге 
массивБ1 (массивБ1 массивов). 

Кроме того, в C# и CLR возможен доступ к злементам массива при помогци 
небезопасного (неверифицируемого) кода. В зтом случае процедура проверки 
индексов массива просто отклгочаетси. Даннан техника применима толбко к мас- 
сивам типа SByte, Byte, Intl6, UIntl6, Int32, UInt32, Int64, UInt64, Char, Single, 
Double, Decimal, Boolean, a также к массивам перечислимого типа или структурБ 1 
значимого типа с полими одного из вБ1шеуказаннБ1х типов. 

Зту могцнуго возможностб следует исполБЗОватБ краине осторожно, так как 
она дает примои доступ к памлти. При зтом вб1ход за границБ1 массива не сопрово- 
ждастси понвлением исклгоченгш; вместо зтого происходит повреждение памнти, 
нарушение безопасности типов и, скорее всего, в системвг безопасности программБг 
понвлнетсл дефект. Позтому сборке, содержагцеи небезопаснБпг код, следует обе- 
спечитБ полное доверие или же предоставитв разрешение Secunity Permission, 
вклгочив своиство Skip Verif ication. 

Следугогции код демонстрирует три варианта доступа к двухмерному массиву, 
вклгочал безопаснвш доступ, доступ через нерегулирнБш массив и небезопаснвш 
доступ: 

using System; 

using System.Diagnostics; 

public static class Program { 

private const Int32 c_numElements = 10000; 

public static void Main() { 

// ОбБлвление двухмерного массива 

Int32[,] a2Dim = new Int32[c_numElements, c_numElements]; 

// ОбБлвление нерегуллрного двухмерного массива (вектор векторов) 

Int32[][] alagged = new Int32[c_numElements] []; 
for (Int32 х = 0; х < c_numElements; x++) 
alagged[x] = new Int32[c_numElements]; 

// 1: Обравдение к алементам стандартнмм, безопаснмм способом 
Safe2DimAnnayAccess(a2Dim) ; 

// 2: Обрашение к злементам с исполнзованием нерегуллрного массива 
SafelaggedAnnayAccess(a3agged) ; 

// 3: Обрашение к злементам небезопаснмм методом 
Unsafe2DimArrayAccess(a2Dim) ; 

} 


private static Int32 Safe2DimAnnayAccess(Int32[,] a) { 
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Int32 sum = 0; 

fon (Int32 х = 0; х < c_numElements; x++) { 

for (Int32 у = 0; у < c_numElements; y++) { 

sum += a[Xj у]; 

} 

} 

return sum; 

} 

private static Int32 SafeDaggedArrayAccess(Int32[][] a) { 

Int32 sum = 0; 

for (Int32 х = 0; х < c_numElements; x++) { 

for (Int32 у = 0; у < c_numElements; y++) { 

sum += a[x] [у]; 

} 

} 

return sum; 

} 

private static unsafe Int32 Unsafe2DimArrayAccess(Int32[, ] a) { 
Int32 sum = 0; 
fixed (Int32* pi = a) { 

for (Int32 х = 0; х < c_numElements; x++) { 

Int32 baseOfDim = х * c_numElements; 
for (Int32 у = 0; у < c_numElements; y++) { 
sum += pi[baseOfDim + у]; 

} 

} 

} 

return sum; 

} 

} 


Метод Unsafe2DimArrayAccess имеет модификатор unsafe, которми необходим 
длл инструкции f ixed нзмка С#. При вмзове компиллтора следует установитБ 
переклгочателБ /unsaf е или флажок Allovv Unsafe Code навкладке Build окнасвоиств 
проекта в программе Microsoft Visual Studio. 

Сугцествугот ситуации, в которБ 1 х <<небезопаснвш» доступ оказншаетсл опти- 
малБНБш, но у него естн три серБезнБ1х недостатка: 

□ код обрагценин к злементам массива менее читабелен и более сложен в написании 
из-за присутствии инструкции f ixed и ввгаислешш адресов памнти; 

□ ошибка в расчетах может привести к перезаписи памлти, не принадлежагцеи 
массиву, в резулвтате возможнб1 разрушение памлти, нарушение безопасности 
типов и потенциалБНБ1е бреши в системе безопасности; 

□ из-за BBicoKoii веронтности проблем CLR запрегцает работу небезопасного 
кода в средах с пониженнвш уровнем безопасности (таких, как Microsoft 
Silverlight). 
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Небезопаснњш доступ к массивам 
и массивм фиксированного размера 

Небезопаснми доступ к массиву нвлнетси краине монднмм средством, так как именно 
такои доступ дает возможностб работатБ: 

□ с злементами управлиемого массива, расположеннБ1ми в куче (как показано 
в предввдушем разделе); 

□ с злементами массива, расположеннБ1ми в неуправллемои куче (пример 
SecureString из главБ 1 14 демонстрирует небезопаснБп! метод доступа к мас- 
сиву, возврашаемому методом SecureStringToCoTaskMemUnicode класса System . 
Runtime . InteropServices.Marshal); 

□ c злементами массива, расположеннвши в стеке потока. 

Если производителБностБ дли вас критична, управлиемБН! массив можно вместо 
кучи разместитв в стеке потока. Дли зтого вам потребуетсл инструкции stackalloc 
изБжа C# (ее принцип деиствин напоминает функцгпо alloca извгка С). Онапозво- 
лиет создаватв одномернБге массивБг злементов значимого типа с нулевои нижнеи 
границеи. При зтом значимвш тип не должен содержатБ никаких полеи ссбшочного 
типа. По сути, вбг вБгделнете блок памнти, с которкш можно работатн при помогци не- 
безопаснБгх указателеи, позтому адрес зтого буфера нелБЗн передаватБ болБшинству 
FCL -методов. Ввгделеннаи в стеке памитв (массив) автоматически освобождаетсл 
после завершенгш метода. Именно за счет зтого и достигаетсл вБшгрвгш в произво- 
дителБности. При зтом длн компилнтора C# должен 6бгтб задан параметр /unsafe. 

Метод StackallocDemo демонстрирует пример исполБЗОвашш инструкции 
stackalloc: 

using System; 

public static class Program { 
public static void Main() { 

StackallocDemo(); 

InlineArrayDemo(); 

} 

private static void StackallocDemo() { 
unsafe { 

const Int32 width = 20; 

Char* pc = stackalloc Char[width]; // B стеке вмделлетсл 

// naMBTb под массив 

String s = "Deffrey Richter"; // 15 символов 

for (Int32 index = 0; index < width; index++) { 
pc[width - index - 1] = 

(index < s.Length) ? s[index] : 

} 
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// Следукидал инструкцил виводит на зкран ". rethciR yenffe3 

Console.WriteLine(new String(pc, 0, width)); 

} 

} 

private static void InlineArrayDemo() { 
unsafe { 

CharArray ca; // Памлтц под массив внделлетсл в стеке 
Int32 widthInBytes = sizeof(CharArray); 

Int32 width = widthInBytes / 2; 

String s = "3effrey Richter"; // 15 символов 

for (Int32 index = 0; index < width; index++) { 
ca.Characters[width - index - 1] = 

(index < s.Length) ? s[index] : 

} 

// Следукидал инструкцил виводит на зкран ". rethciR yerffe3 

Console.WriteLine(new String(ca.CharacterSj <д, width)); 

} 

} 

} 

internal unsafe struct CharArray { 

// Зтот массив встраиваетсл в структуру 
public fixed Char Characters[20]; 

} 


Так как массивм относлтсл к ссмлочнмм типам, поле массива, определенное 
в структуре, содержит указателБ или ссбшку на зтот массив; при зтом сам он рас- 
полагаетсл вне памити структурвк Впрочем, сугцествует возможностб встроитБ 
массив непосредственно в структуру. Bbi зто видели в показанном коде на примере 
структурБ 1 CharArray. При зтом должнб1 соблгодатБСи следугогцие условин: 

□ тип должен 6б1тб структурои (значимкш типом), встраиватБ массивБ1 в класс 
(ссбшочнбш тип) нелБЗи; 

□ поле или структура, в которои оно определено, должно 6bitb помечено моди- 
фикатором unsafe; 

□ поле массива должен 6bitb помечено модификатором f ixed; 

□ массив должен 6bitb одномернБш и с нулевои нижнеи границеи; 

□ злементБ 1 массива могут принадлежатв толбко к типам: Boolean, Char, SByte, 
Byte, Int32, UInt32, Int64, UInt64, Single и Double. 

ВстроеннБ1е массивБ 1 обБино применнготсл в сценарилх, работагогцих с не- 
безопаснвш кодом, в котором неуправлнемал структура даннБ 1 х также содержит 
встроеннБш массив. Впрочем, никто не запрегцает исполвзоватБ их и в других слу- 
чаих, например, как показано ранее в методе InlineArrayDemo, которвш по-своему 
решает ту же задачу, что и метод StackallocDemo. 





Глава 17. ДелегатБ! 


В зтои главе рассказмваетсл о чрезвмчаино полезном механизме, которми ис- 
полћзуетсл уже много лет и назмваетси функцинми обратного вмзова. В Microsoft 
.NET Framework зтот механизм поддерживаетсн при помоши делегатов (delegates). 
В отличие от других платформ, например неуправлнемого измка С++, делегатм 
обладагот более широкои функционалвноствЈО. Например, они обеспечивагот 
безопасностБ типов при вмполнении обратного вмзова (способствуи решениго 
однои из важнеиших задач CLR). Кроме того, они обеспечивагот возможностб по- 
следователћного вмзова несколгжих методов, а также вмзова как статических, так 
и зкземплирнмх методов. 


Знакомство с делегатами 

Функцин qsort исполнпгошеи средм С получает указателБ на функциго обратного 
вБ 130 ва длл сортировки злементов массивов. В Windows механизм обратного вбп 
зова исполБзуетсн оконнбши процедурами, процедурами перехвата, асинхроннБш 
вБ 130 вом процедур и др. В .NET Framework методБ1 обратного вБ 130 ва также имегот 
многочисленнвге примененип. К примеру, можно зарегистрироватБ такои метод длн 
полученгш различнБгх уведомлении: о необработаннвгх исклгоченгшх, изменении 
состоишш окон, вБгборе пунктов менго, измененгшх фаиловои системвг и заверше- 
нии асинхроннБгх операции. 

В неуправлнемом пзикс С/С++ адрес функции — не более чем адрес в памнти, 
не несушии дополнителвнои информации. В нем не содержитсн информацин нн 
о количестве ожидаемвгх функциеи параметров, ни об их типе, ни о типе возвра- 
гцаемого функциеи значенгш, ни о правилах ввгзова. Другими словами, функции 
обратного вБгзова С/С++ не обеспечивагот безопасноств типов (хотн их и отличает 
вБгсокаи скоростБ вБшолненип). 

В .NET Framework функции обратного вкгзова играгот не менее важнуго ролв, чем 
при неуправлиемом программировании дли Windows. Однако даннаи платформа 
предоставлнет в распорнжение разработчика делегатов — механизм, безопаснвш по 
отношениго к типам. Рассмотрим пример обБивленгш, создангш и исполБЗОвангш 
делегатов: 
using System; 

using System.Windows.Forms; 
using System.IO; 


// ОбБПВление делегата; зкземплнр ссмлаетсн на метод 
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// с параметром типа Int32, возврашаклции значение void 
internal delegate void Feedback(Int32 value); 

public sealed class Program { 
public static void Main() { 

StaticDelegateDemo(); 

InstanceDelegateDemo(); 

ChainDelegateDemol(new Program()); 

ChainDelegateDemo2(new Program()); 

} 

private static void StaticDelegateDemo() { 

Console.WriteLine("- Static Delegate Demo -"); 

Counter(l, 3, null); 

Counter(lj 3, new Feedback(Program.FeedbackToConsole)); 

Counter(lj 3^ new Feedback(FeedbackToMsgBox)); // Префикс "Program." 

// не обвзателен 

Console.WriteLine(); 

} 

private static void InstanceDelegateDemo() { 

Console.WriteLine("- Instance Delegate Demo -"); 

Program p = new Program(); 

Counter(lj 3, new Feedback(p.FeedbackToFile)); 

Console.WriteLine(); 

} 

private static void ChainDelegateDemol(Program p) { 

Console.WriteLine("- Chain Delegate Demo 1 -"); 

Feedback fbl = new Feedback(FeedbackToConsole); 

Feedback fb2 = new Feedback(FeedbackToMsgBox); 

Feedback fb3 = new Feedback(p.FeedbackToFile); 

Feedback fbchain = null; 

fbchain = (Feedback) Delegate.Combine(fbChainj fbl); 

fbchain = (Feedback) Delegate.Combine(fbChainj fb2); 

fbchain = (Feedback) Delegate.Combine(fbChainj fb3); 

Counter(lj 2, fbchain); 

Console.WriteLine(); 
fbchain = (Feedback) 

Delegate.Remove(fbChainj new Feedback(FeedbackToMsgBox)); 

Counter(lj 2, fbchain); 

} 

private static void ChainDelegateDemo2(Program p) { 

Console.WriteLine("- Chain Delegate Demo 2 -"); 

Feedback fbl = new Feedback(FeedbackToConsole); 

Feedback fb2 = new Feedback(FeedbackToMsgBox); 

Feedback fb3 = new Feedback(p.FeedbackToFile); 

Feedback fbchain = null; 

продолжение & 
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fbchain += fbl; 
fbchain += fb2; 
fbchain += fb3; 

Counter(lj 2j fbchain); 

Console.WriteLine(); 

fbchain -= new Feedback(FeedbackToMsgBox); 

Counter(lj 2j fbchain); 

} 

private static void Counter(Int32 fromj Int32 to, Feedback fb) { 
for (Int32 val = from; val <= to; val++) { 

// Если указанм методм обратного вузова, вмзмваем их 
if (fb != null) 
fb(val) ; 

} 

} 

private static void FeedbackToConsole(Int32 value) { 

Console.WriteLine("Item=" + value); 

} 

private static void FeedbackToMsgBox(Int32 value) { 

MessageBox.Show("Item=" + value); 

} 

private void FeedbackToFile(Int32 value) { 

using (StreamWriter sw = new StreamWriter("Status", true)) { 
sw.WriteLine("Item=" + value); 

} 

} 

Рассмотрим зтот код более подробно. Прежде всего следует обратитБ внимание 
наобЂнвление внутреннего делегата Feedback. Он задает сигнатуру методаобрат- 
ного вБ 130 ва. ДаннБш делегат определнет метод, принимагогции один параметр типа 
Int32 и возврагцагогции значение void. Он напоминает клгочевое слово typedef из 
С/С++, которое предоставлиет адрес функции. 

Класс Program определлет закрБгтћги статическии метод Counter. Он перебирает 
целБге числа в диапазоне, заданном аргументами f rom и to. Также он принимает 
параметр f b, которвш ивлнетсл ссбшкои на делегат Feedback. Метод Counter пере- 
бирает числа в цикле и длл каждого из них при условии, что переменнаи f b не 
равна null, вБгполниет метод обратного внгзова (определеннБш переменнои fb). 
При зтом методу обратного внгзова передаетсн значение обрабатвгваемого злемента 
и его номер. Реализацин данного метода может обрабатБгватв злементБг так, как 
считает нужнБгм. 
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Обратнми Bbi 30 B статических методов 

Tenepb, когда мм разобрали принцип работм метода Counten, рассмотрим процедуру 
исполћзовании делегатов дли вмзова статических методов. Длн примера возћмем 
метод StaticDelegateDemo из представленного в предмдугцем разделе кода. 

Метод StaticDelegateDemo вмзмвает метод Counten, передаваи в третБем па- 
раметре f b значение null. В резулкгате при обработке злементов не задеиствуетси 
метод обратного вмзова. 

При втором вмзове метода Counten методом StaticDelegateDemo третћему па- 
раметру передаетси толбко что созданнБш делегат Feedback. Зтот делегат служит 
оболочкои длл другого метода, позволнн вбшолнитб обратнБпг вбгзов последнего 
косвенно, через оболочку. В рассматриваемом примере имн статического метода 
Pnognam . FeedbackToConsole передаетси конструктору Feedback, указБшан, что 
именно длл него требуетси создатБ оболочку. Возврагценнан оператором new ссвшка 
передаетсл третиему параметру метода Counten, которБш в процессе ввшолненгш 
будет ББгзБгватБ статическии метод FeedbackToConsole. Последнии же просто вбг- 
водит на консолб строку с названием обрабатвгваемого злемента. 

ПРИМЕЧАНИЕ 

Метод FeedbackToConsole определен втипе Program какзакритБ 1 и, но при зтом мо- 
жет 6biTb вмзван методом Counter. Так как оба метода определенв! в пределах одного 
типа, проблем с безопасноствк) не возникает. Flo даже если бм метод Counter бмл 
определен в другом типе, зто не сказалосв бм на работе коде. Другими словами, 
если код одного типа вмзмвает посредством делегата закрмтв 1 и член другого типа, 
проблем с 6e3onacHOCTbio или уровнем доступа не возникает, если делегат создан 
в коде, имекнцем нужнми уровени доступа. 

Третии вбгзов метода Counten внутри метода StaticDelegateDemo отличаетсн 
от второго тем, что делегат Feedback ивлнетсн оболочкои длл статического метода 
Pnognam . FeedbackToMsgBox. Именно метод FeedbackToMsgBox создает строку, 
указвгвагогцуго на обрабатБгваемБш злемент, которан затем вбгводитсл в окне в виде 
сообгценин. 

В зтом примере ничто не нарушает безопасноств типов. К примеру, при соз- 
дании делегата Feedback компилнтор убеждаетси в том, что сигнатурвг методов 
FeedbackToConsole и FeedbackToMsgBox типа Pnognam совместимвг с сигнатурои 
делегата. Зто означает, что оба метода будут прггниматБ один и тот же аргумент 
(типа Int32) и возврагцатБ значение одного и того же типа (void). Однако попро- 
буем определитБ метод FeedbackToConsole вот так: 
private static Boolean FeedbackToConsole(String value) { 

} 

B зтом случае компилнтор ввгдаст сообгценгге об ошибке (сигнатура метода 
FeedbackToConsole не соответствует типу делегата): 

еггог CS0123: No overload for ’ FeedbackToConsole ' matches delegate 'Feedback' 
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Как С#, так и CLR подцерживагот ковариантностБ и контравариантностБ ссмлоч- 
нмх типов при привнзке метода к делегату. КовариантностЂ (covariance) означает, 
что метод может возвратитБ тип, производнми от типа, возврагцаемого делегатом. 
Контравариантноств (contra-variance) означает, что метод может приниматБ па- 
раметр, которми нвлнетсл базовмм длн типа параметра делегата. Например: 
delegate Object MyCallback(FileStream s); 

Определив делегат таким образом, можно получитБ зкземплир зтого делегата, 
свизаннБш с методом, прототип которого вбшллдит примерно так: 

String SomeMethod(Stream s); 

ЗдесБ тип значенгш, возврагцаемого методом SomeMethod (тип String), нвлнетсн 
производнвш от типа, возврагцаемого делегатом (Object); такаи ковариантноств 
разрешена. Тип параметра метода SomeMethod (тип Stream) ивлиетсл базоввш 
классом длл типа параметра делегата (FileStream); такаи контравариантностБ 
тоже разрешена. 

Обратите внимание, что ковариантностБ и контравариантностБ поддерживаготсн 
ТОЛБКО ДЛН ССБ1ЛОЧНБ1Х ТИПОВ, HO Н6 длн значимБгх типов или значенгш void. К при- 
меру, свпзатБ следугогции метод с делегатом MyCallback невозможно: 

Int32 SomeOtherMethod(Stream s); 

Несмотрл на то что тип значенгш, возврагцаемого методом SomeOtherMethod 
(то еств Int32), ивлнетсл производнвш от типа значенгш, возврагцаемого методом 
MyCallback (то еств Object), такан форма ковариантности невозможна, потому что 
Int32 — зто значимБпг тип. ЗначимБге типбг и void не могут исполБЗОватБСи кова- 
риантно и контравариантно, потому что их структура памлти меннетсл, в то времн 
как дгш ссБглочнБгх типов структурои памлти в лгобом случае остаетсл указателв. 
К счастБго, при попБгтке вбшолнитб запрегценнБге деиствгш компилнтор возврагцает 
сообгцение об ошибке. 


Обратнми внзов зкземпл^рнмх методов 

Мбг рассмотрели процедуру внгзова при помогци делегатов статических методов, 
но они позволнгот вБгзБгватБ также зкземплирнБге методБг заданного обвекта. Рас- 
смотрим механизм зтого вкгзова на примере метода InstanceDelegateDemo из по- 
казанного ранее кода. 

Обратите внимание, что обвект р типа Program создаетсн внутри метода 
InstanceDelegateDemo. При зтом у него отсутствугот зкземшшрнвге поли и свои- 
ства, посколвку он сконструирован с демонстрационнБши целнми. Когда при вбгзовс 
метода Counter создаетсл делегат Feedback, его конструктору передаетсл обвект 
р. FeedbackToFile. В резулвтате делегат преврагцаетсл в оболочку длл ссбглки на 
метод FeedbackToFile, которБпг ивлнетсл не статическгш, а зкземшшрнвш мето- 
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дом. Когда метод Counten обрагцаетсл к методу обратного вмзова, которми задан 
аргументом fb, вмзмваетсл зкземплнрнми метод FeedbackToFile, а адрес толбко 
что созданного обвекта р передаетсл зтому методу в качестве ненвного аргумента 

this. 

Метод FeedbackToFile отличаетсн отметодов FeedbackToConsole и FeedbackTo- 
MsgBox тем, что открмвает фаил и дописмвает в его конец строку (созданнми им 
фаил Status находитсл в папке AppBase приложенин). 

Как видите, делегатм могут служитБ оболочкои как длл статических, так и длл 
зкземплирнБгх методов. В последнем случае делегат должен знатБ, какои зкзем- 
плнр обвекта будет обрабатБ1ватк вБгзБшаемБпТ им метод. Создавал оболочку длн 
зкземплнрного метода, bbi предоставлнете коду внутри обвекта доступ к различнвш 
членам зкземплнра обвекта. Зто означает наличие у обвекта состоннгш, которое 
может исполБЗОватБСи во времл ввшолненгш метода обратного вБгзова. 


Тонкости исполБЗОванил делегатов 

На перввш взгллд работатв с делегатами легко. Они определиготсл при помогци 
клгочевого слова C# delegate, оператор new создает зкземплнрвг делегатов, а длл 
обратного ввгзова служит уже знакомвш синтаксис. В последнем случае вместо 
имени метода указвшаетсн ссБшагогцаисл на делегат переменнаи. 

На самом деле все обстоит несколвко сложнее, чем демонстриругот приведеннБШ 
примерБк ПолБЗОватели просто не осознагот всеи сложности процесса благодарн 
работе компилиторов и CLR. Однако в зтом разделе рассматриваготси все тонко- 
сти реализации делегатов, так как зто поможет нам поннтб принцип их работнг 
и научитБСн применнтБ их зффективно и рационалвно. Также будут рассмотренБ1 
некоторБШ дополнителБНБге возможности делегатов. 

ВнимателБно посмотрите на следугогцуго строку: 

internal delegate void Feedback(Int32 value); 

Она заставлнет компиллтор создатв полное определение класса, которое bki- 
гллдит примерно так: 

internal class Feedback : System.MulticastDelegate { 

// Конструктор 

public Feedback(Object object, IntPtr method); 

// Метод, прототип которого задан в исходном тексте 
public virtual void Invoke(Int32 value); 

// Методм, обеспечиваклцие асинхроннии обратнми вмзов 
public virtual IAsyncResult BeginInvoke(Int32 value, 

AsyncCallback callback, Object object); 
public virtual void EndInvoke(IAsyncResult result); 

} 
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Класс, определеннми компилнтором, содержит четмре метода: конструктор, 
а также методм Invoke, Beginlnvoke и Endlnvoke. В зтои главм мм в основном бу- 
демрассматриватБ конструктор и метод Invoke. Методм Beginlnvoken Endlnvoke 
относитсн к модели асинхронного программированин .NET Framework, которан 
сеичас считаетси устаревшеи. Она бмла заменена асинхроннмми операцинми, 
которме рассматриваготси в главе 27. 

Исследовав итоговуго сборку при помогци утилитм ILDasm.exe, можно убе- 
дитбси, что компиллтор деиствителБно автоматически сгенерировал зтот класс 
(рис 17.1). 



Рис. 17.1. Сгенерированнне компиллтором метаданнне делегата 


В зтом примере компилитор определил класс Feedback, производш>ш от типа 
System.MulticastDelegate из библиотеки классов Framework Class Fibrary (все 
типБ 1 делегатов нвлпготси потомками MulticastDelegate). 


ВНИМАНИЕ 

Класс System.MulticastDelegate лвллетсл производнмм от класса System.Delegate, 
которни, в cbohd очередБ, наследуетот кпасса System.Object. Два класса делегатов 
полвилисб исторически, в то времл как в FCL предполагалсч толбко один. Вам сле- 
дует помнитб об обоих классах, так какдаже если внбрат в качестве базового класс 
MulticastDelegate, все равно иногда приходитсл работатв с делегатами, исполизу 10 - 
[цими методн кпасса Delegate. Скажем, именно зтому кпассу принадпежат статиче- 
ские методн Combine и Remove (отом, зачем они нужнм, мн поговорим 4yTb позже). 
Сигнатурм зтих методов указв 1 вакзт, что они принимакзт параметрв! класса Delegate. 
Так кактип вашего делегата лвллетсл производнмм от класса MulticastDelegate, длл 
которого базовмм лвлчетсл класс Delegate, методам можно передавати зкземплчри 1 
типа делегата. 


Зто закрБ1ТБ1и класс, так как делегат обБивлиетсн в исходном коде с модифи- 
катором internal. Если о6бнвитб его с модификатором public, сгенерированнБш 
компилнтором класс Feedback будет открБггБш. Следует помнитб, что делегатБ 1 
можно определнтБ как внутри класса (вложеннвге в другои класс), так и в глобалв- 
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нои области видимости. По сути, так как делегатм нвлнготсл классами, их можно 
определитБ в лгобом месте, где может 6бгтб определен класс. 

JI 1061,1c типб1 делегатов — зто потомки класса MulticastDelegate, от которого 
они наследугот все полн, своиства и методБ1. Три самБ1х важнБгх поли описапБ! 
в табл. 17 . 1 . 


Таблица 17.1. Важнеишие закрнтБ 1 е полн класса MulticastDelegate 


Поле 

Тип 

Описание 

_target 

System.Object 

Если делегат лвллетсл оболочкои статического 
метода, зто поле содержит значение null. Если де- 
легат лвллетсл оболочкои зкземплнрного метода, 
поле ссБшаетсн на обвект, с которБхм будет работатв 
метод обратного вћгзова. Другими словами, поле 
указнвает на значение, которое следует передатћ 
параметру this зкземпллрного метода 

_methodPtr 

System.IntPtr 

Внутреннее целочисленное значение, исполвзуемое 
CLR длл идентификации метода обратного вмзова 

_invocationList 

System.Object 

Зто поле обшчно имеет значение null. Оно может 
ссБшатБсл на массив делегатов при построении из 
них цепочки (об зтом mbi поговорим чутБ позже) 


Обратите внимание, что конструктор всех делегатов принимает два параметра: 
ссвшку на обвект и целое число, ссБшагогцеесл на метод обратного вБгзова. Но в тексте 
исходного кода туда передаготсн такие значенгш, как Program. FeedbackToConsole 
или р. FeedbackToFile. Вероитно, весв ваш ошлт программировангш подсказвшает, 
что зтот код компилироватБСи не будет! 

Однако компилитор знает о том, что создастси делегат, и, проанализировав код, 
определнет обвект и метод, на которвге mbi ссБшаемсн. СсБшка на обвект передаетсл 
в параметре object конструктора. Специалвное значение IntPtr (получаемое из 
маркеров метаданнвш MethodDef или MemberRef ), идентифициругогцее метод, пере- 
даетсн в параметре method. В случае статических методов параметр ob ject передает 
значение null. Внутри конструктора значенгш зтих двух аргументов сохраннтси в 
закрБ 1 ТБ 1 х полнх _target и _methodPtr соответственно. Кроме того, конструктор 
присваивает значение null полго _invocationList. О назначении зтого поли mbi 
подробно поговорим в разделе, посвнгценном цепочкам делегатов. 

Таким образом, лгобои делегат — зто всего лишб обертка длн метода и обрабатБ 1 - 
ваемого зтим методом обвекта. Позтому в следугогцих строчках кода переменнвге 
fbStatic и f blnstance ссвшаготсн на два разшлх обвекта Feedback, инициализи- 
рованнБ 1 х, как показано на рис. 17.2: 

Feedback fbstatic = new Feedback(Program.FeedbackToConsole) ; 

Feedback fblnstance = new Feedback(new Program().FeedbackToFile); 
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Рис. 17.2. Верхнлл переменнал сснтаетсл на делегата статического метода, 
нижнлл — на делегата зкземпллрного метода 


Теперд, когда вм познакомилисћ с процессом созданин делегатов и их внутрен- 
неи структурои, поговорим о методах обратного вмзова. Рассмотрим егце раз код 
метода Counter: 

private static void Counter(Int32 from, Int32 to, Feedback fb) { 
for (Int32 val = from; val <= to; val++) { 

// Если указанм методн обратного вмзова, BbBbiBaeM их 
if (fb != null) 
fb(val); 

} 

} 

Обратите внимание на строку под комментарием. Инструкцин if сначала про- 
вериет, не содержит ли переменнан f b значении null. Если проверка проидена, обра- 
гцаемсн к методу обратного вмзова. Такан проверка необходима потому, что f b — зто 
всего лишб переменнаи, ссмлагогцаисн на делегат Feedback; она может иметБ, в том 
числе, значение null. Может показатћси, что происходит вмзов функции f b, которои 
передаетси один параметр (val). Но у нас нет функции с таким именем. И компилнтор 
генерирует код вмзова метода Invoke делегата, так как он знает, что переменнан f b 
ссмлаетсн на обвект делегата. Другими словами, при обнаружении строки 
fb(val); 

компилнтор генерирует такои же код, как и дли строки: 
fb.Invoke(val) ; 

ВосполБЗОвавшисБ утилитои ILDasm.exe длнисследовангш кодаметода Counten, 
можно убедитБСн, что компилнтор генерирует код, вмзмвагогции метод Invoke. 
Далее показан IL -код метода Counten. Команда в строке I L_0009 нвлнетси вмзовом 
метода Invoke обвекта Feedback. 

.method private hidebysig static void Counter(int32 from, 

int32 'to', 

class Feedback fb) cil managed 

{ 

// Code size 23 (0x17) 

.maxstack 2 

.locals init (int32 V_0) 
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IL_0000 : 
IL_0001 : 
IL_0002 : 
IL_0004: 
IL_0005: 
IL_0007: 
IL_0008: 
IL_0009: 
IL_000e: 
IL_000f: 
IL_0010: 
IL_0011: 
IL_0012: 
IL_0013: 
IL_0014: 
IL_0016: 
} // end 


ldarg.0 
stloc.0 
br.s IL_0012 
ldarg.2 

brfalse.s IL_000e 

ldarg.2 

ldloc.0 

callvirt instance void Feedback::Invoke(int32) 
ldloc.0 
ldc.i4.1 
add 

stloc.0 
ldloc.0 
ldarg.l 
ble.s IL_0004 
ret 

of method Program::Counter 


B прпнцппе метод Counter можно изменитБ, вклгочив в него нвнми вмзов Invoke: 

private static void Counter(Int32 from, Int32 to, Feedback fb) { 
for (Int32 val = from; val <= to; val++) { 

// Если указанн методн обратного вмзова, внзмваем их 
if (fb != null) 
fb.Invoke(val); 

} 

} 


I [адс 10 сг>, вм помните, что компилитор определиет метод Invoke при определе- 
нии класса Feedback. Вмзмваи зтот метод, он исполБзует закрмтме по.ти _target 
и _methodPtr дли вмзова желаемого метода на заданном обвекте. Обратите внима- 
ние, что сигнатура метода Invoke совпадает с сигнатурои делегата, ведБ и делегат 
Feedback, и метод Invoke принимагот один параметр типа Int32 и возврагцагот 
значение void. 


Обратнни внзов несколБких методов 
(цепочки делегатов) 

ДелегатБ 1 полезнв 1 сами по себе, но егце более полезнБ 1 ми их делает механизм 
цепочек. Цепочкоп (chaining) назћшаетсл коллекцин делегатов, дагогцал возмож- 
ностб вБ13Б1ватБ все методБ 1 , представленнБ 1 е зтими делегатами. Что 6 б 1 понптб, 
как работает цепочка, вернитесБ к коду в начале зтои главБ1 и наидите там метод 
ChainDelegateDemol. В зтом методе после инструкции Console .WriteLine созда- 
готсн три делегата, на которкге ссБшаготсн переменнБге f bl, f b2 и f b3 соответственно 
(рис. 17.3). 
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Рис. 17.3. Началвное состолние делегатов, на KOTopbie ссмлактгсл 
nepeivieHHbie fbl , fb2 и fb3 


Ссмлочнан переменнан на делегат Feedback, которан назмваетси f bChain, долж- 
на ссмлатћсн на цепочку, или набор делегатов, служагцих оболочками длл методов 
обратного вмзова. Инициализацил переменнои f bChain значением null указмвает 
на отсутствие методов обратного вмзова. Открмтми статическии метод Combine 
класса Delegate добавлиет в цепочку делегатов: 

fbchain = (Feedback) Delegate.Combine(fbChainj fbl); 

При вмполнении зтои строки метод Combine видит, что мм пмтаемсн обЂединитћ 
значение null с переменнои fbl. В итоге он возврагцает значение в переменнуго 
fbl, а затем заставлнет ncpc.vieiiiivio fbChain сослатЂСн на делегата, на которого уже 
ссмлаетсн переменнаи f bl. Зта схема демонстрируетсл на рис. 17.4. 



Рис. 17.4. Состочние делегатов после добавлениа в цепочку нового члена 
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Чтобм добавитБ в цепочку еше одного делегата, снова восполћзуемсн методом 

Combine: 

fbchain = (Feedback) Delegate.Combine(fbChain, fb2); 

Метод Combine видит, что переменнан f bChain уже ссвшаетсн на делегата, позто- 
му он создает нового делегата, которвш присваивает своим закрвгтвш полнм _target 
и _methodPtr некоторнге значенин. В данном случае они не важнБг, но важно, что 
поле _invocationList инициализируетсн ссбшкои на массив делегатов. Первому 
злементу массива (с индексом 0) присваиваетси ссвшка на делегат, служагции обо- 
лочкои метода FeedbackToConsole (именно на зтот делегат ссншаетсл переменнан 
f bChain). Второму злемепту массива (с индексом 1) присваиваетси ссвшка на де- 
легат, служагции оболочкои метода FeedbackToMsgBox (на зтот делегат ссБшаетси 
переменнан fb2). Напоследок переменнои f bChain присваиваетси ссвшка на вновб 
созданнБги делегат (рис. 17.5). 



Рис. 17.5. ДелегатБ! после вставки в цепочку второго члена 


Длн добавленгш в цепочку третвего делегата снова вБгзвшаетси метод Combine: 
fbchain = (Feedback) Delegate.Combine(fbChain, fb3); 

И снова, видл, что переменнаи fbChain уже ссвшаетсн на делегата, метод соз- 
дает очередного делегата, как показано на рис. 17.6. Как и в предБгдугцих случаих, 
новбпг делегат присваивает началвнвге значенгш своим закрвгтвгм полнм _target 
n_methodPtr, в то времн как поле _invocationList инициализируетсл ссбшкои на 
массив делегатов. Первому и второму злементам массива (с индексами 0 и 1) при- 
сваиваготси ссбшки на те же делегатнг, на которнге ссБшалсн предБгдугции делегат. 
Третии злемент массива (с индексом 2) становитсн ссбшкои на делегата, служагцего 
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оболочкои метода FeedbackToFile (именно на зтого делегата ссмлаетсн переменнан 
fb3). Наконец, переменнои f bChain присваиваетси ссмлка на вновћ созданного 
делегата. При отом ранее созданнми делегат и массив, на которми ссмлаетсл его 
поле _invocationList, теперг подлежат обработке механизмом уборки мусора. 



Рис. 17.6. Окончателвнни вид цепочки делегатов 


После вмполненин кода, создагогцего цепочку, переменнан f bChain передаетси 
методу Counter: 

Counter(lj 2, fbChain); 

Метод Counten содержит код ненвного вмзова метода Invoke дли делегата 
Feedback. Впрочем, об зтом мм уже говорили. Когда метод Invoke вмзмваетси дли 
делегата, ссмлагогцегоси на переменнуго f bChain, зтот делегат обнаруживает, что 
значение полн _invocationList отлично от null. Зто приводит к вмполненшо 
цикла, перебирагогцего все злементм массива, вмзмваи дли них метод, оболочкои 
которого служит указаннми делегат. В нашем примере методм вмзмваготсл в сле- 
дугогцеи последователБности: FeedbackToConsole, FeedbackToMsgBox и, наконец, 
FeedbackToFile. 

Реализацин метода Invoke класса Feedback вмглидит примерно так (в псевдо- 
коде): 
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public void Invoke(Int32 value) { 

Delegatef] delegateSet = _invocationList as Delegatef]; 
if (delegateSet != null) { 

// Зтот массив указмвает на делегатвц которме следует вмзвати 
foreach (Feedback d in delegateSet) 
d(value); // Bbi30B каждого делегата 
} else { 

// Зтот делегат определлет исполвзуемми метод обратного BbBOBa. 

// Зтот метод BbBbiBaeTcn длл указанного обБекта. 

_methodPtr . Invoke(_target, value) ; 

// Строка вмше - имитацил реалцного кода. 

// TOj что происходит в деиствителцностиЈ не вмражаетсл средствами С#. 

} 

} 


Длн удаленин делегатов из цепочки примениетсл статическии метод Remove 
обвекта Delegate. Зта процедура демонстрируетсл в конце кода метода Chain- 
DelegateDemol: 

fbchain = (Feedback) Delegate.Remove( 

fbChainj new Feedback(FeedbackToMsgBox)); 

Метод Remove сканирует массив делегатов (c конца и до члена с нулевмм индек- 
сом), управлиемми делегатом, на которми ссмлаетсн первми параметр (в нашем 
примере зто f bChain). Он шцет делегат, полн _ta nget и _methodPtn которого совпа- 
дагот с соответствугогцими полими второго аргумента (в нашем примере зто новми 
делегат Feedback). При обнаружении совпаденин, если в массиве осталосБ более 
одного злемента, создаетсл новми делегат — создаетсл массив _invocationList, 
которми инициализируетсл ссмлкои на все злементм исходного массива за ис- 
клгочением удалнемого, — после чего возврагцаетсл ссмлка на нового делегата. При 
удалении последнего злемента цепочки метод Remove возврагцает значение null. 
Следует помнитб, что метод Remove за один раз удаллет липњ одного делегата, а не 
все злементм с указаннмми значенгшми полеи _tanget и _methodPtn. 

Ранее ммтакже рассматривали делегат Feedback, возврагцагогции значение типа 
void. Однако зтот делегат можно бмло определитБ и так: 

public delegate Int32 Feedback(Int32 value); 

B зтом случае псевдокод метода Invoke вБгглидел 6бг следугогцим образом: 

public Int32 Invoke(Int32 value) { 

Int32 result; 

Delegatef] delegateSet = _invocationList as Delegatef]; 
if (delegateSet != null) { 

// Массив указмвает на делегати, которие нужно вмзватц 
foreach (Feedback d in delegateSet) 
result = d(value); // Вмзов делегата 
} else { 

// Зтот делегат определпет исполцзуемми метод обратного BbBOBa. 

// Зтот метод BbBbiBaeTcn длл указанного обцекта. 
result = _methodPtr.Invoke(_target, value); 
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// Строка Bbime - имитацил реалцного кода. 

// TOj что происходит в деиствителцностиЈ не вмражаетсл средствами С#. 

} 

return result; 

} 

По мере вмзова отделБнмх делегатов возврагцаемое значенне сохраннетсн в пере- 
меннои result. После завершенгш цикла в зтои переменнои оказБшаетси толбко 
резулБтат вБгзова последнего делегата (предБвдугцие возврагцаемБге значенгш от- 
брасБгваготси); именно зто значение возврагцаетси коду, ввгзвавшему метод Invoke. 

Поддержка цепочек делегатов в C# 

Чтобвг упроститв задачу разработчиков, компшштор C# автоматически предостав- 
лиет перегруженнвге версии операторов += и -= дли зкземплнров делегатов. Зти 
операторвг вБгзБгвагот методвг Delegate . Combine гг Delegate . Remove соответственно. 
Они упрогцагот построение цепочек делегатов. В резулвтате компилиции методов 
ChainDelegateDemol гг ChainDelegateDemo2 (см. пример в начале главвг) получаетсн 
идентичнБги IL-code. Единственнан разница в том, что благодарн операторам += 
и -= исходнбги код метода ChainDelegateDemo2 получаетсл прогце. 

Длн доказателБСтва идентичности сгенерируите IL -код обоих методов и изучите 
его при помогци утилитвг ILDasm.exe. Вбг убедитесБ, что компилитор C# деистви- 
телвно заменнет все операторвг += и -= ввгзовами статических методов Combine 
и Remove типа Delegate соответственно. 


ДополнителБНме средства управленин 
цепочками делегатов 

Итак, вбг научилисБ создаватБ цепочки делегатов и вБгзвгватв все их компонентвг. 
Последнцц возможностб реализуетсл благодарц наличиго в методе Invoke кода, 
просматривагогцего все злементвг массива делегатов. И хотн зтого простого алго- 
ритма хватает длн болвшггнства сценариев, у него еств рнд ограничении. К примеру, 
сохраннетсл толбко последнее из значении, возврагцаемнгх методами обратного 
вБгзова. ПолучитБ все осталвнвге значенин нелБЗн. И зто не единственное ограниче- 
ние. Скажем, в ситуации, когда один из делегатов в цепочке становитси причинои 
исклгоченгш или блокируетсл на оченв долгое времн, вБгполнение цепочки останав- 
ливаетсл. Поннтно, что даннвги алгоритм не отличаетсл надежностнго. 

В качестве алвтернативБг можно восполБЗОватБСл зкземплирнвгм методом 
GetlnvocationList класса MulticastDelegate. Зтот метод позволнет в нвном виде 
ввгзватБ лгобои из делегатов в цепочке: 

public abstract class MulticastDelegate : Delegate { 

// Создает массив, каждии злемент которого ссмлаетсд 
// на делегата в цепочке 

public sealed override Delegate[] GetInvocationList(); 

} 
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Метод GetlnvocationList работает с обЂектами классов, производнмх от 
MulticastDelegate. Он возвравдает массив ссмлок, каждал из котормх указмвает 
на какои-то делегат в цепочке. По сути, зтот метод создает массив и инициализи- 
рует его злементм ссмлками на соответствугогцие делегатм; в конце возврагцаетсн 
ссмлканазтот массив. Если поле _invocationList содержит null, возврагцаемми 
массив будет содержатЂ всего один злемент, ссмлагогциисн на единственного деле- 
гата в цепочке — зкземплир самого делегата. 

НаписатБ алгоритм, в нвном виде вмзмвагогцгш каждми злемент массива, не- 
сложно: 

using System; 

using System.Reflection; 

using System.Text; 

// Определение компонента Light 
internal sealed class Light { 

// Метод возврацает состолние обБекта Light 
public String SwitchPosition() { 
return "The light is off"; 

} 

} 

// Определение компонента Fan 
internal sealed class Fan { 

// Метод возврацает состолние обиекта Fan 
public String Speed() { 

throw new InvalidOperationException("The fan broke due to overheating"); 

} 

} 

// Определение компонента Speaker 
internal sealed class Speaker { 

// Метод возврацает состолние обБекта Speaker 
public String Volume() { 

return "The volume is loud"; 

} 

} 

public sealed class Program { 

// Определение делегатов, позволлклцих запрашиватв состолние компонентов 
private delegate String GetStatus(); 

public static void Main() { 

// ОбБлвление пустои цепочки делегатов 
GetStatus getStatus = null; 

// Создание трех компонентов и добавление в цепочку 
// методов проверки их состолнил 

getStatus += new GetStatus(new Light().SwitchPosition); 
getStatus += new GetStatus(new Fan().Speed); 


продолжение & 
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getStatus += new GetStatus(new Speaken().Volume); 

// Своднми отчет o состолнии трех компонентов 
Console.WniteLine(GetComponentStatusRepont(getStatus) ); 

} 

// Метод запрашивает состолние компонентов и возврашает информациш 
pnivate static Stning GetComponentStatusRepont(GetStatus status) { 

// Если цепочка пуста, ничего делатц не нужно 
if (status == null) netunn null; 

// Построение отчета o состолнии 
StningBuilden nepont = new StningBuilden(); 

// Создание массива из делегатов цепочки 

Delegatef] annayOfDelegates = status.GetInvocationList(); 

// Циклическал обработка делегатов массива 
foneach (GetStatus getStatus in annayOfDelegates) { 

tny { 

// Получение строки состолнил компонента и добавление ее в отчет 
nepont . AppendFonmat( "{0}{1}{1}" j getStatus() , Envinonment . NewLine) 

} 

catch (InvalidOpenationException e) { 

// B отчете генерируетсл записц об ошибке длл зтого компонента 
Object component = getStatus.Tanget; 
nepont . AppendFonmat( 

"Failed to get status fnom {1}{2}{0} Ennon: {3}{0}{0}", 
Envinonment.NewLine л 

((component == null) ? "" : component.GetType() + "."), 

getStatus.Method.Name, 

e.Message); 

} 

} 

// Возврашение сводного отчета вшзшваклцему коду 
netunn nepont.ToStning(); 

} 

} 


Резулћтат вБшолненин зтого кода вбнлндит так: 
The light is off 

Failed to get status fnom Fan.Speed 

Ennon: The fan bnoke due to ovenheating 


The volume is loud 
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Обоб|деннне делегатн 

Много лет назад, когда среда .NET Framework толбко начинала разрабатмватБСи, 
в Microsoft ввели поннтие делегатов. По мере добавленин в FCL классов понвлнлисб 
и новме типм делегатов. Со временем их накопилосв изридное количество. Толбко 
в библиотеке MSCorLib.dll их около 50. Вот некоторме из них: 

public delegate void TryCode(Object userData); 
public delegate void WaitCallback(Object state); 
public delegate void TimerCallback(Object state); 
public delegate void ContextCallback(Object state); 
public delegate void SendOrPostCallback(Object state); 
public delegate void ParameterizedThreadStart(Object obj); 

Вм не заметили определенное сходство в отобраннмх мнои делегатах? Fia самом 
деле они одинаковм: переменнан лгобого из зтих делегатов должна ссмлатБСи на 
метод, получаклции Object и возврагцагогции void. Соответственно весБ зтот набор 
делегатов не нужен — вполне можно обоитисв одним. 

Так как современнан версгш .NET Framework поддерживает обобгценгш, нам на 
самом деле нужно всего лишб несколБКО обобгценнкгх делегатов (определеннБгх 
в пространстве имен System), представлнгогцих методвг, которБге могут приниматБ 
до 16 аргументов: 

public delegate void Action(); // Зтот делегат не обобтеннии 

public delegate void Action<T>(T obj); 

public delegate void ActioncTl, T2>(T1 argl, T2 arg2); 

public delegate void Action<Tl, T2, T3>(T1 argl, T2 arg2, ТЗ arg3); 

public delegate void Action<Tl, ..., T16>(T1 argl, ..., T16 argl6); 

B .NET Framework имеготсл 17 делегатов Action, от не имегогцих аргументов 
вообгце до имегогцих 16 аргументов. Чтобвг ввгзватБ метод с болБшим количеством 
аргументов, придетсл определитв собственного делегата, но зто уже маловероитно. 

Кроме делегатов Action в .NET Framework имеетсл 17 делегатов Func, которвге 
позволнгот методу обратного ввгзова вернутв значение: 

public delegate TResult Func<TResult>( ); 

public delegate TResult Func<T, TResult>(T arg); 

public delegate TResult Func<Tl, T2, TResult>(Tl argl, T2 arg2); 

public delegate TResult Func<Tl, T2, ТЗ, TResult>(Tl argl, T2 arg2, ТЗ arg3); 

public delegate TResult Func<Tl,..., T16, TResult>(Tl argl, ..., T16 argl6); 

Вместо определенгш собственнБгх типов делегатов рекомендуетсн по мере воз- 
можности исполвзоватБ обобгценнБгх делегатов; ведв зто уменБшает количество 
типов в системе и упрогцает код. Однако, если нужно передатв аргумент по ссншке, 
исполБзул клгочевБге слова ref или out, может потребоватвсл определение соб- 
ственного делегата: 

delegate void Bar(ref Int32 z); 
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Аналогично нужно деиствоватБ в ситуацгмх, когда требуетсл передатБ делегату 
переменное число параметров при помогци клгочевого слова params, если вбг хоти- 
те задатБ значенгш по умолчаниго дли аргументов делегата или если потребуетсн 
установитБ ограничение длл аргумента-типа. 

При работе с делегатами, исполБзугогцими обобгценнБге аргументБг гг возврагцаго- 
гцими значенггн, не следует забвгватБ про коварггантностБ гг контравариантностБ, так 
как зто расгнирлет областк применении делегатов. ДополнителБнан информацгш 
по зтои теме приведена в главе 12. 


Упро1деннБ1и синтаксис 
работн с делегатами 

Многие программиствг не лгобит делегатов из-за сложного синтаксиса. К примеру, 
рассмотрим строку: 

buttonl.Click += new EventHandlen(buttonl_Click) ; 

Здесв buttonl_Click — метод, которБш вбггллдит примерно так: 

void buttonl_Click(Object sender, EventAngs e) { 

// Деиствил после шелчка на кнопке... 

} 

Перван строка кода как 6 бг регистрирует адрес метода buttonl_Click в кнопке, 
чтобвг при гцелчке на неи вБгзвгвалсл метод. Программистам обвгчно кажетсл не- 
разумнвгм создаватБ делегат EventHandlen всего лишб длл того, что6бг указатБ на 
адрес метода buttonl_Click. Однако данннги делегат нужен с.реде CLR, так как он 
служит оберткои, гарантиругогцеи безопасностн типов при ввгзове метода. Оберт- 
ка также поддерживает вбгзов зкземплирнвгх методов и создание цепочек. Тем не 
менее программиствг не хотлт вникатБ во все зти детали и предпочли 6 бг записатБ 
код следугогцим образом: 
buttonl.Click += buttonl_Click; 

К счастБго, компилитор C# поддерживает упрогценнБги синтаксис при работе 
с делегатами. Однако перед тем как переити к рассмотренггго соответствугогцих воз- 
можностеи, следует заметитв, что зто — не более чем упрогценнБге путгг созданггн IL- 
кода, необходимого CLR длн нормалБнои работнг с делегатами. Кроме того, следует 
учитБгватБ, что описание упрогценного синтаксиса работнг с делегатами относитсн 
исклгочителБно к С#; другими компилиторами он может и не поддерживатБСи. 

Упро 1 цение 1: не создаем обг»ект делегата 

Как вбг уже видели, C# позволнет указвгватв ими метода обратного внгзова без 
создангш делегата, служагцего длн него оберткои. Вот егце один пример: 
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internal sealed class AClass { 

public static void CallbackWithoutNewingADelegateObject() { 

ThreadPool.QueueUserWorkItem(SomeAsyncTask, 5); 

} 

private static void SomeAsyncTask(Object o) { 

Console.WriteLine(o); 

} 

} 

Статическии метод QueueUserWorkItem класса ThreadPool ожидает ссмлку на 
делегата WaitCallback, которми, в cboio очередБ, ссмлаетсн на метод SomeAsyncTask. 
Так как компиллтор в состолнии догадатћсл, что именно имеетсл в виду, можно 
опуститБ строки, относнгциесн к созданиго делегата WaitCallback, чтобм упроститБ 
чтение и понимание кода. В процессе компилнции IL -код, генериругогции нового 
делегата WaitCallback, создаетсл автоматически, а записБ нвлиетсл всего лишб 
упрогценнои формои синтаксиса. 

Упроицение 2: не определлем метод обратного вмзова 

В приведенном фрагменте кода метод обратного вмзова SomeAsyncTask передаетси 
методу QueueUserWorkItem класса ThreadPool. C# позволнет подставитБ реализациго 
метода обратного вмзова непосредственно в код, а не в отделБнми метод. Скажем, 
наш код можно записатћ так: 

internal sealed class AClass { 

public static void CallbackWithoutNewingADelegateObject() { 

ThreadPool.QueuellserWorkItem( obj => Console.WriteLine(obj ), 5); 

} 

} 

Обратите внимание, что перввш «аргумент» метода QueueUserWorkItem (он 
вБгделен полужирнв 1 м шрифтом) представлнет собои фрагмент кода! Формалвно 
в C# он назБшаетси лнмбда-виражением (lambda expression) и распознаетсл по 
наличиго оператора =>. Ллмбда-ввфаженин исполБзуготсл в тех местах, где компи- 
лнтор ожидает присутствил делегата. Обнаружив лимбда-вБ 1 ражение, компилнтор 
автоматически определлет в классе новбги закрБ 1 твш метод (в нашем примере — 
AClass). Зтот метод назБ 1 ваетси анонимноп функциеп (anonymous function), так как 
вм обмчно не знаете его имени, которое автоматически создаетсл компилитором. 
Впрочем, никто не мешает исследоватБ полученнши код при помогци утилитм 
ILDasm.exe. Именно она помоглаузнатБ послекомпилиции написанного фрагмента 
кода, что методу бвшо присвоено ими <CallbackWithoutNewingADelegateObject 

>b _0, а также, что метод принимает всего один аргумент типа Object, возврагцаи 

значение типа void. 

Компилитор вБ 1 бирает дли метода имн, начинагогцеесл с символа <, потому что 
в C# идентификаторБ 1 не могут содержатБ зтот символ. Такои подход гарантирует, 
что программист не сможет случаино Bbi6paTb дли какого-нибудБ из своих методов 



454 Глава 17. Делега™ 


ими, совпадаквдее с автоматически созданнмм компилитором. При зтом, если в C# 
идентификаторм не могут содержатБ символа <, в CLR зто разрешено. Несмотрн 
на возможностб обранденгш к методу через механизм отражешш путем передачи 
его имени в виде строки, следует помнитб, что компилитор может по-разному ге- 
нерироватБ зто ими при каждом следугогцем проходе. 

Утилита ILDasm.exe позволнет также заметитв, что компилнтор C# применнет 
к методу атрибут System . Runtime . CompilerServices . CompilerGeneratedAttribute. 
Зто дает инструментам и утилитам возможностб поннтб, что метод создан автомати- 
чески, а не написан программистом. В зтот сгенерированнвш компилитором метод 
и помегцаетсн код, находнгцииси справа от оператора =>. 

ПРИМЕЧАНИЕ 

При написании ллмбда-вБ1ражении невозможно применитБ к сгенерированному 
компиллтором методу полБЗОвателБСкие атрибутБ! или модификаторм (например, 
unsafe). Впрочем, о6бмно зто не лвллетсл проблемои, так как созданнме компиллто- 
ром анонимнме методм всегдазакрБ1тм. Каждми такои метод лвллетсл статическим 
или нестатическим в зависимости от того, будет ли он иметБ доступ к каким-либо 
зкземплчрнмм членам. Соответственно, применлтБ к зтим методам модификаторм 
public, protected, internal, virtual, sealed, override или abstract просто нетребуетсл. 


НаписаннБги код компилитор C# переписБгвает примерно таким образом (ком- 
ментарии вставленБг mhoio): 

internal sealed class AClass { 

// Зто закрнтое поле создано длп кзшированип делегата 
// Преимушество: CallbackWithoutNewingADelegateObject не будет 
// создаватБ новми обљект при каждом вћвове 

// Недостатки: кзшированнне обљектм недоступнм длп сборшика мусора 
[CompilerGenerated] 

private static WaitCallback <>9_CachedAnonymousMethodDelegatel; 

public static void CallbackWithoutNewingADelegateObject() { 

if (<>9_CachedAnonymousMethodDelegatel == null) { 

// При первом вмзове делегат создаетсл и кзшируетсл 

<>9_ CachedAnonymousMethodDelegatel = 

new WaitCallback(<CallbackWithoutNewingADelegateObject>b _0); 

} 

ThreadPool.QueueUserWorkItem(<>9_CachedAnonymousMethodDelegatel, 5); 

} 

[CompilerGenerated] 

private static void <CallbackWithoutNewingADelegateObject>b_0( 

Object obj) { 

Console.WriteLine(obj); 

} 

} 


Лимбда-вБгражение должно соответствоватБ сигнатуре делегата WaitCallback: 
возврагцатБ void и приниматБ параметр типа Object. Впрочем, и указал ими пара- 
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метра, просто поместив переменнуго obj слева от оператора =>. Расположеннши 
справа от зтого оператора метод Console .WriteLine деиствителБно возврагцает 
void. Если бм расположенное справа вмражение не возврагцало void, сгенериро- 
ваннни компилнтором код просто проигнорировал бм возврагценное значение, ведБ 
в противном случае не удалосв 6bi соблгости требовангш делегата WaitCallback. 

Также следует отметитБ, что анонимнан функцин помечаетсн как pnivate; в итоге 
доступ к методу остаетсн толбко у кода, определенного внутри зтого же типа (хотн 
отражение позволит узнатв о сугцествовании метода). Обратите внимание, что 
анонимнБш метод определен как статическии. Зто свнзано с отсутствием у кода 
доступа к каким-либо членам зкземплнра (ведв метод CallbackWithoutNewingADe 
legateObject сам по себе статическии). Впрочем, код может обрагцатБСн к лго6бш 
определеннБш в классе статическим полим или методам. Например: 

internal sealed class AClass { 

private static String sm_name; // Статическое поле 

public static void CallbackWithoutNewingADelegateObject() { 

ThreadPool.QueueUserWorkItem( 

// Код обратного вшова может обрашатБсв к статическим членам 
obj =>Console.WriteLine(sm_name+ " + obj), 

5); 

} 

} 

Не будв метод CallbackWithoutNewingADelegateObject статическим, код ано- 
нимного метода мог 6бг содержатБ ссбглки на членБг зкземшшра. Но даже при от- 
сутствии таких ссбшок компилнтор все равно генерирует статическии анонимнБпг 
метод, так как он зффективнее зкземплнрного метода, потому что ему не нужен 
дополнителБНБш параметр this. Если же в коде анонимного метода наличествугот 
ССБ1ЛКИ на членБг зкземплнра, компилнтор создает нестатическии анонимнкш метод: 

internal sealed class AClass { 

private String m_name; // Поле акземплвра 

// Метод зкземплвра 

public void CallbackWithoutNewingADelegateObject() { 

ThreadPool.QueueUserWorkItem( 

// Код обратного вмзова может ссмлатБсв на члени зкземпллра 
obj => Console.WriteLine(m_name+ " + obj), 

5); 

} 

} 

Имена аргументов, которвге следует передатв лнмбда-вБграженшо, указБгваготсн 
слева от оператора = >. При зтом следует придерживатвси правил, которвге мбг рас- 
смотрим на примерах: 

// Если делегат не содержит аргументов, исполБзуите круглие скобки 
Func<String> f = () => "Deff"; 

// Длл делегатов с одним и более аргументами 

продолжение & 
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// можно в ввном виде указати тит >1 

Func<Int32j String> f2 = (Int32 n) => n.ToStringO; 

Func<Int32j Int32, String> f3 = 

(Int32 nl, Int32 n2) => (nl + n2) .ToStringO; 

// Компиллтор может самостолтелвно определити типн длв делегатов 

// с одним и более аргументами 

Func<Int32, String> f4 = (n) => n.ToStringO; 

Func<Int32, Int32, String> f5 = (nl, n2) => (nl + n2).ToString(); 

// Если аргумент у делегата всего один, круглме скобки можно опустити 
Func<Int32, String> f6 = n => n.ToString(); 

// Длд аргументов ref/out нужно в лвном виде указувати ref/out и тип 
Bar b = (out Int32 n) => n = 5; 

Предположим, что в последнем случае делегат Bar определен следугогцим об- 
разом: 

delegate void Bar(out Int32 z); 

Тело анонимнои функции записмваетсл справа от оператора =>. Оно обмчно 
представлнет собои простое или сложное вмражение, возврагцагогцее некое значение. 
В рассмотренном примере зто бмло лимбда-вмражение, возврагцагогцее строки всем 
переменнмм делегата Func. Чагце всего тело анонимнои функции состоит из однои 
ггнструкции. К примеру, вмзванному методу ThreadPool . QueueUserWorkItem бмло 
передано ллмбда-вмражение, что привело к вмзову метода Console.WriteLine 
(возврагцагогцего значение типа void). 

Чтобм вставитБ в тело функции несколгжо инструкции, заклгочите их в фигур- 
нме скобки. Если делегат ожидает получитћ возврагцаемое значение, не забудг>те 
ггнструкциго return, как показано в следугогцем примере: 

Func<Int32, Int32, String> f7 = (nl, n2) => { 

Int32 sum = nl + n2; return sum.ToStringO; }; 


ВНИМАНИЕ 

Хотл зто и не кажетсп очевиднБ1м, основнаа вБ 1 года от исполБЗОванип ллмбда- 
вБ1ражении состоит в том, что они снижакзтуровенБ неопределенности вашего кода. 
06б1чно приходитсл nncaTb отдел^нми метод, присваивати ему имл и передаватв 
зто имл методу, в котором требуетсл делегат. Именно имл позволлет ссмлатисл на 
фрагмент кода. И если ссмлка на один и тот же фрагмент требуетсл в различннх 
местах программм, создание метода — зто самое правилиное решение. Если же 
обраидение к фрагменту кода предполагаетсл всего одно, на помоиди приходлт 
ллмбда-вмраженил. Именно они позволлкдт встраиваљ фрагменти1 кода в нужное 
место, избавллл от необходимости их именованил и повмшал тем саммм продуктив- 
HOCTb работм программиста. 
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ПРИМЕЧАНИЕ 

Механизм анонимншх методов впервие полвилсл в C# 2.0. Подобно ллмбда- 
вв 1 раженилм (полвившимсл в C# 3.0), анонимнме методв! описмвак)т синтаксис 
созданил анонимнмх функции. Рекомендуетсл исполвзовати ллмбда-вмраженил 
вместо анонимнв 1 х методов, так как их синтаксис более компактен, что упрошает 
чтение кода. Разумеетсл, компиллтор до сих пор поддерживаетанонимнв 1 е функции, 
так что необходимости вноситв исправленил в код, написаннми на C# 2.0, нет. Тем 
не менее в зтои книге рассматриваетсл толико синтаксис ллмбда-вмражении. 


Упро 1 дение 3: не создаем обертку длп локалБнмх 
переменнмх длн передачи их методу обратного вмзова 

Вм уже видели, что код обратного вмзова может ссмлатћсн на другие членм класса. 
Но иногда бмвает нужно обратитБСн из зтого кода к локалБному параметру или 
переменнои внутри определиемого метода. Вот интереснми пример: 

internal sealed class AClass { 

public static void UsingLocalVariablesInTheCallbackCode(Int32 numToDo) { 

// ЛокалБнме переменнне 

Int32[] squares = new Int32[numToDo]; 

AutoResetEvent done = new AutoResetEvent(false); 

// Вмполнение задач в других потоках 

for (Int32 n = 0; n < squares.Length; n++) { 

ThreadPool.QueueUserWorkItem( 

°bj => { 

Int32 num = (Int32) obj; 

// Обнчно решение зтои задачи требует болише времени 
squares[num] = num * num; 

// Если зто последнпн задача, продолжаем вмполннтб главнши поток 
if (Interlocked.Decrement(ref numToDo) == 0) 
done.Set(); 

n); 

} 

// Ожидаем завершенин осталинмх потоков 
done.WaitOne(); 

// Вмвод резулБтатов 

for (Int32 n = 0; n < squares.Length; n++) 

Console.WriteLine("Index {0}, Square={l}"j n, squares[n]); 

} 


Зтот пример демонстрирует, ндсколбко легко в C# реализуготсл задачи, счи- 
тавшиеси достаточно сложнмми. В представленном здесБ методе определен един- 
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ственнши параметр numToDo и две локалБнме переменнме squanes и done. Ссмлки 
на зти переменнме присутствугот в теле лимбда-вмраженин. 

А теперБ представим, что код из лимбда-вмраженин помешен в отделћнми ме- 
тод (как того требует CLR). Каким образом передатБ туда значенин переменнмх? 
Длн зтого потребуетсн вспомогателБнми класс, определигогции поле длл каждого 
значенгш, которое требуетсн передатћ в код обратного вмзова. Кроме того, зтот код 
следует определитБ во вспомогателБном классе как зкземплнрнБш метод. Тогда ме- 
тод UsingLocalVariablesInTheCallbackCode создаст зкземплнр вспомогателБного 
класса, присвоит полнм значенгш локалБНБгх переменнБгх и, наконец, создаст обвект 
делегата, свнзаннБш с вспомогателБНБгм классом и зкземплирнмм методом. 

ПРИМЕЧАНИЕ 

Когда ламбда-вБ1ражение заставллет компиллтор генерироватБ класс с превраш,ен- 
нмми в полл параметрами/локалБнмми переменнБ1ми, увеличиваетсл времл жизни 
обнекта, на которми ссилакзтсл зти переменнме. Обмчно параметрБ1/локалБнме 
переменнБ1е уничтожакзтсл после завершенил метода, в котором они исполБзукзтсл. 
В данном же случае они остакзтсл, пока не будет уничтожен обЂект, содержашии 
поле. В болБшинстве приложении зто не имеет особого значенил, тем не менее зтот 
факт следует знатБ. 


Зто нуднал и чреватач ошибками работа, и разумеетсн, компилитор лучше вбшол- 
нит ее за вас. ПриведеннБш код он перепишет примерно так (комментаргш мои): 

internal sealed class AClass { 

public static void UsingLocalVariablesInTheCallbackCode(Int32 numToDo) { 

// ЛокалБнме переменнне 
WaitCallback callbackl = null; 

// Создание зкземплпра вспомогателвного класса 

<>с_ DisplayClass2 classl = new <>c_DisplayClass2(); 

// Инициализацил полеи вспомогателцного класса 
classl . numToDo = numToDo; 
classl.squares = new Int32[classl.numToDo]; 
classl.done = new AutoResetEvent(false); 

// Вмполнение задач в других потоках 
for (Int32 n = 0; n < classl.squares.Length; n++) { 
if (callbackl == null) { 

// HoBbin делегат привлзнваетсл к обцекту вспомогателцного класса 
// и его анонимному зкземпллрному методу 
callbackl = new WaitCallback( 

classl.<UsingLocalVariablesInTheCallbackCode>b_0); 

} 

ThreadPool.QueueUserWorkItem(callbackl, n); 

} 
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// Ожидание завершенил осталиншх потоков 
classl . done.WaitOne( ); 

// Вшвод резулитатов 

for (Int32 n = 0; n < classl.squares.Length; n++) 
Console.WriteLine("Index {0}, Square={l}"j n, classl.squares[n]); 

} 

// Вспомогателиному классу присваиваетсл HeočbNHoe имл, чтобш 
// избежати конфликтов и предотвратити доступ из класса AClass 
[CompilerGenerated] 

private sealed class <>c_DisplayClass2 : Object { 

// B коде обратного вшзова длл каждои локалинои переменнои 

// исполнзуетсл одно открмтое поле 

public Int32[] squares; 

public Int32 numToDo; 

public AutoResetEvent done; 

// Открмтши конструктор без параметров 
public <>с_ DisplayClass2 { } 

// Открмтши зкземпллрнми метод с кодом обратного вшзова 

public void <UsingLocalVariablesInTheCallbackCode>b _ 0(Object obj) { 

Int32 num = (Int32) obj; 
squares[num] = num * num; 

if (Interlocked.Decrement(ref numToDo) == 0) 
done.Set(); 

} 

} 


ВНИМАНИЕ 

Без сомненил, у лсбого программиста возникает соблазн исполвзоватв ллмбда- 
вираженил там, где зто уместно и не уместно. Лично л привмк к ним не сразу. Beflb 
код, которни Bbi пишете внутри метода, на самом деле зтому методу не принадлежит, 
что затруднлет отладку и пошаговое вмполнение. Хотл л бнл откровенно поражен 
тем, что отладчик Visual Studio позволлл вмполнлљ ллмбда-вмраженил в моем ис- 
ходном коде в пошаговом режиме. 

Л установил ддл себл правило: если в методе обратного вмзова предполагаетсл более 
трех строк кода, не исполвзоватв ллмбда-вмраженил. Вместо зтого л пишу метод 
вручнукз и присваивак) ему имл. Впрочем, при разумном подходе ллмбда-вмраженил 
способнм сервезно повмсиљ продуктивноств работм программиста и упростиљ под- 
держку кода. В следукидем примере кода ллмбда-вв1раженил смотрлтсл естественно, 
и без них написание, чтение и редактирование кода бмло бм намного сложнее: 

// Создание и инициализацип массива String 

String[] names = { "Jeff", "Kristin", "Aidan", "Grant" }; 

// Извлечение имен co строчнои буквои 'a' 

Char charToFind = 'a'; 

продолжение & 
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names = Аггау. FindAll(names ^ name => name.Index0f(charToFind) >= 0); 

// Преобразование всех символов строки в верхнии регистр 
names = Аггау .ConvertAll(nameSj name => name.ToUpper( )); 

// Вувод резулБтатов 

Аггау. ForEach(names, Console.WriteLine); 


Делегатн и отражение 

Все показаннме в зтои главе примерм исполБЗОвании делегатов требовали, чтобм 
разработчик заранее знал прототип метода обратного вмзова. Скажем, если пере- 
меннан fb ссмлаетсл на делегата Feedback (см. листинг первого примера в зтои 
главе), код обрагценин к делегату мог бм вмглидетБ примерно так: 

fb(item); // параметр item определен как Int32 

Как видите, разработчик должен знатБ количество и тип параметров метода об- 
ратного вБ130ва. К счаствго, зта информации почти всегда доступна разработчику, 
так что написатв подо6нбш зтому код — не проблема. 

Впрочем, в отделБНБ 1 х редких ситуацилх на момент компиллции зти сведенин от- 
сутствугот. В главе 11 при обсуждении типа EventSet приводилсн соответствугогции 
пример со словарем, храннгцим набор разнвш типов делегатов. Длн ввгоова собвпил 
во времн вБшолненин производилсн поиск и вбгоов делегата из словарн. Однако при 
зтом 6бшо невозможно узнатв во времн компилиции, какои делегат будет ввгован 
и какие параметрБ1 следует передатв его методу обратного вБгоова. 

К счастБГО, в классе System.Reflection.MethodInfo имеетсл метод Create- 
Delegate, позволнгогции создаватв и вБ13Б1ватБ делегатБ 1 даже при отсутствии 
сведении о них на момент компилиции. Вот как вбшлндлт перегруженнБ 1 е версии 
зтого метода: 

public abstract class Methodlnfo : MethodBase { 

// Создание делегата, служашего оберткои статического метода. 
public virtual Delegate CreateDelegate(Type delegateType); 

// Создание делегата, служашего оберткои зкземпллрного метода; 

// target ссмлаетсл на аргумент 'this’. 
public virtual Delegate CreateDelegate(Type delegateType, Object target); 

} 

После того как делегат будет создан, его можно ввговатБ методом DynamicInvoke 
класса Delegate, которкш вбшлндит примерно так: 

public abstract class Delegate { 

// Вмзов делегата с передачеи параметров 

public Object DynamicInvoke(params Objectf] args); 

} 
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При исполћзовании API отражешш (см. главу 23) необходимо сначала получитБ 
обвект Methodlnf о длн метода, дли которого требуетсл создатБ делегата. Затем вбн 
зов метода CreateDelegate создает новбги обвект типа, производного от Delegate 
и определнемого первБш параметром delegateType. Если делегат представллет 
зкземплнрнБ 1 и метод, также следует передатБ CreateDelegate параметр target, 
обозначаклции обвект, которБпЗ должен передаватБСл зкземплпрному методу как 
параметр this. 

Метод DynamicInvoke класса System . Delegate позволиет задеиствоватБ метод 
обратного вБ13ова делегата, передаваи набор параметров, определлемБ1х во вре- 
мп вБшолненгш. При вБ130ве метода DynamicInvoke провернетсл совместимостБ 
переданнБ1х параметров с параметрами, ожидаемБши методом обратного вБ130ва. 
Если параметрв 1 совместимБр вБшолннетсн обратнБп! вбиов; в противном случае 
генерируетсн исклгочение ArgumentException. Даннвп! метод возврагцает обвект, 
которвпЗ 6бш возврагцен методом обратного вБгзова. 

Рассмотрим пример примененгш методов CreateDelegate и DynamicInvoke: 

using System; 

using System.Reflection; 

using System.IO; 

// НесколБко разнмх определении делегатов 

internal delegate Object TwoInt32s(Int32 nl, Int32 n2); 

internal delegate Object OneString(String sl); 


public static class DelegateReflection { 
public static void Main(String[] args) { 
if (args.Length < 2) { 

String usage = 

@"Usage:" + 

"{0} delType methodName [Argl] [Arg2]" + 

"{0} where delType must be TwoInt32s or OneString" + 

"{0} if delType is TwoInt32s, methodName must be Add or Subtract" + 

"{0} if delType is OneString, methodName must be NumChars or Reverse" 

+ 

"{ 0 }" + 

"{0}Examples:" + 

"{0} TwoInt32s Add 123 321" + 

"{0} TwoInt32s Subtract 123 321" + 

"{0} OneString NumChars V'Hello there\"" + 

"{0} OneString Reverse V'Hello there\""; 

Console.WriteLine(usage, Environment.NewLine); 
return; 


// Преобразование аргумента delType в тип делегата 
Туре delType = Туре .GetType(args[0] ); 
if (delType == null) { 

Console.WriteLine("Invalid delType argument: " + args[0]); 

продолжение & 
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return; 

} 

Delegate d; 
try { 

// Преобразование аргумента Argl в метод 
Methodlnfo mi = 

typeof(DelegateReflection).GetTypeInfo().GetDeclaredMethod(args[1]) 

// Создание делегата, служатего оберткои статического метода 
d = mi.CreateDelegate(delType); 

} 

catch (ArgumentException) { 

Console.WriteLine("Invalid methodName argument: " + args[l]); 
return; 

} 

// Создание массива, содержашего аргументт, 

// передаваемуе методу через делегат 

Objectf] callbackArgs = new Object[args . Length 2]; 

if (d.GetType() == typeof(TwoInt32s)) { 
try { 

// Преобразование аргументов типа String в тип Int32 
for (Int32 a = 2; a < args.Length; a++) 

callbackArgs[a 2] = Int32.Parse(args[a]); 

} 

catch (FormatException) { 

Console.WriteLine("Parameters must be integers."); 
return; 

} 

} 

if (d.GetType() == typeof(OneString)) { 

// Простое копирование аргумента типа String 
Array.Copy(args, 2, callbackArgs, 0, callbackArgs.Length); 

} 

try { 

// Bbi30B делегата и вмвод резулнтата 

Object result = d.DynamicInvoke(callbackArgs); 

Console.WriteLine("Result = " + result); 

} 

catch (TargetParameterCountException) { 

Console.WriteLine("Incorrect number of parameters specified."); 

} 


// Метод обратного вћвова, принимаклции два аргумента типа Int32 
private static Object Add(Int32 nl, Int32 n2) { 
return nl + n2; 

} 
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// Метод обратного внзоваЈ приниманкции два аргумента типа Int32 
private static Object Subtract(Int32 nl^ Int32 п2) { 
return nl n2; 

} 

// Метод обратного вмзова., приниманнции один аргумент типа String 
private static Object NumChars(String sl) { 
return sl.Length; 

} 

// Метод обратного вмзова., приниманкции один аргумент типа String 
private static Object Reverse(String sl) { 
return new String(sl.Reverse() .ТоАггау ()); 

} 



Глава 18 . НастраиваемБ1е 
атрибутБ! 


В зтои главе описмваетси один из саммх новаторских механизмов Microsoft .NET 
Framework — механизм настраиваемих атрибутов (custom attributes). Именно на- 
страиваемме атрибутм позволнгот снабжатв кодовме конструкции декларативнмми 
аннотациими, наделлн код особмми возможностими. Настраиваемме атрибутм 
дагот возможностб задатБ информациго, применимуго практически к лгобои записи 
таблицм метаданнмх. Информациго об зтих расширнеммх метаданнмх можно запра- 
шиватБ во времн вмполненгш с целБГО динамического измененин хода вмполненгш 
программм. Настраиваемме атрибутм применнготсн в различнмх технологинх .NET 
Framework (Windows Forms, WPF, WCF и т. п.), что позволиет разработчикам легко 
вмражатћ свои намеренин в коде. Таким образом, умение работатБ с настраиваеммми 
атрибутами необходимо всем разработчикам ,NET Framework. 


Сфера примененил 
настраиваемнх атрибутов 

Атрибутм public, private, static и им подобнме применнготси как к типам, так 
и к членам типов. Никто не станет споритБ с тем, что атрибутћг полезнБг — но 
как насчет возможности задании собственнБ1х атрибутов? Предположим, нужно 
не просто определитв тип, но и каким-либо образом указатн на возможностб его 
удаленного исполБЗОвашш посредством сериализации. Или, к примеру, назначитв 
методу атрибут, которБш означает, что дли вБшолненгш метода должнб1 6бпб полу- 
ченБ 1 некоторБШ разрешенгш безопасности. 

Разумеетсн, создаватн настраиваемБге атрибутБг и применнтБ их к типам и мето- 
дам оченБ удобно, однако длн зтого компиллтор должен распознаватн зти атрибутБ 1 
и заноситБ соответствугогцуго информациго в метаданнвге. ФирмБнразработчики 
предпочитагот не публиковатБ исходнбпг код своих компилиторов, позтому спе- 
циалистБг Microsoft предложили алБтернативнБпг способ работнг с настраиваемБши 
атрибутами, которБге представлнгот собои могцнбпг механизм, полезнБпг как при 
разработке, так и при вБшолнении приложении. ОпределлтБ и задеиствоватБ на- 
страиваемБге атрибутБ1 может кто угодно, а все СЕК-совместимвге компилнторБ1 
должнб1 их распознаватБ и генерироватБ соответствугогцие метаданнвге. 

Следует пониматв, что настраиваемБге атрибутБг представлигот собои лишб 
средство передачи некои дополнителвнои информации. Компилитор помегцает 
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зту информациго в метаданнме управлнемого модули. БолБшаи частБ атрибутов 
длл компилитора просто не имеет значенгш; он обнаруживает их в исходном коде 
и создает длл них соответствуклцие метаданнме. 

Библиотека классов .NET Framework (FCL) вклгочает определенгш сотен на- 
страиваеммх атрибутов, которме вм можете исполБЗОватБ в своем коде. Вот не- 
сколбко примеров: 

□ Атрибут Dlllmpont при применении к методу информирует CLR о том, что метод 
реализован в неуправлнемом коде указаннои DLL -библиотеки. 

□ Атрибут Senializable при применении к типу информирует механизмБг се- 
риализации о том, что зкземплирнБге поли доступнБг длн сериализации и десе- 
риализации. 

□ Атрибут AssemblyVension при применении к сборке задает версиго сборки. 

□ Атрибут Flags при применении к перечислимому типу преврагцает перечисли- 
MBiii тип в набор битоввгх флагов. 

Рассмотрим код с множеством примененнБ 1 х к нему атрибутов. В C# имена на- 
страиваемБ1х атрибутов помегцаготсн в квадратнБ1е скобки непосредственно перед 
именем класса, обвекта и т. п. Не пБ 1 таитесв поннтб, что именно делает код; н всего 
лишб хочу показатБ, как вбшлидлт атрибутБК 

using System; 

using System.Runtime.IntenopServices; 

[StructLayout(LayoutKind.Sequential, ChanSet = CharSet.Auto)] 
internal sealed class OSVERSIONINFO { 
public OSVERSIONINFO() { 

OSVersionlnfoSize = (UInt32) Marshal.SizeOf(this); 

} 

public UInt32 OSVersionlnfoSize = 0; 
public UInt32 MajorVersion = в; 
public UInt32 MinorVersion = в; 
public UInt32 BuildNumber = в; 
public UInt32 Platformld = в; 

[MarshalAs(UnmanagedType.ByValTStr, SizeConst = 128)] 
public String CSDVersion = null; 

} 

internal sealed class MyClass { 

[DllImport("Kernel32", CharSet = CharSet.Auto, SetLastError = true)] 
public static extern Boolean GetVersionEx([In, Out] OSVERSIONINFO ver); 

} 

B данном случае атрибут StructLayout применлетсл к классу OSVERSIONINFO, 
атрибут MarshalAs — к полго CSDVersion, атрибут Dlllmport — к методу GetVersionEx, 
аатрибутБ! In и Out — к параметру ver MeTOflaGetVersionEx. В каждом лзбткс опре- 
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деллетсн свои синтаксис примененин настраиваеммх атрибутов. Например, в Visual 
Basic .NET вместо квадратннх скобок исполБзуготсн угловвге (< >). 

CLR позволиет применитБ атрибутБ1 ко всему, что может 6bitb представлено 
метаданнБ1ми. Чагце всего они примениготсл к записим в следугогцих таблицах 
определении: TypeDef (классвг, структурБг, перечисленггн, интерфеисБг и делегатБг), 
MethodDef (конструкторБг), ParamDef , FieldDef, PropertyDef, EventDef , AssemblyDef 
и ModuleDef. B частности, C# позволиет применнтБ настраиваемБге атрибутБг толб- 
ко к исходному коду, определнгогцему такие злементкг, как сборкгг, модули, типбг 
(класс, структура, перечисление, интерфеис, делегат), поли, методкг (в том числе 
конструкторвг), параметрвг методов, возврагцаемвге значении методов, своиства, 
собвгтин, параметрвг обобгценного типа. 

Вбг можете задатБ префикс, указБгвагогции, к чему будет применен атрибут. 
Возможнвге вариантБг префиксов представленвг в показанном далее фрагменте 
кода. Впрочем, как поннтно из предвгдугцего примера, компилитор часто способен 
определитБ назначение атрибута даже при отсутствии префикса. ОблзателвнБге 
префиксБг вБгделенБг полужирнБгм шрифтом: 

using System; 

[assembly: SomeAttr] // Примендетсл к сборке 

[module: SomeAttr] // Применаетсн к модулк) 

[type: SomeAttr] // Применлетсл к типу 

internal sealed class SomeType<[typevar : SomeAttr] T> { // Применлетсл 

// к переменнои обобтенного типа 

[field: SomeAttr] // Применлетсл к полш 

public Int32 SomeField = 0; 

[return: SomeAttr] // Применлетсл к возвратаемому значенив 

[method: SomeAttr] // Применлетсл к методу 

public Int32 SomeMethod( 

[param: SomeAttr] // Применлетсл к параметру 
Int32 SomeParam) { return SomeParam; } 


[property: SomeAttr] // Применлетсл к своиству 
public String SomeProp { 

[method: SomeAttr] // Применлетсл к механизму доступа get 
get { return null; } 

} 


[event: SomeAttr] // Применлетсл к собмтилм 

[field: SomeAttr] // Применлетсл к поллм, созданнмм компиллтором 

[method: SomeAttr] // Применлетсл к созданним 

// компиллтором методам add и remove 
public event EventHandler SomeEvent; 

} 

ТеперБ, когда вбг знаете, как применнтБ настраиваемБге атрибутБг, даваите раз- 
беремсн, что онгг собои представлнгот. Настраиваемвги атрибут — зто всего лггшб 
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зкземплнр типа. Длн соответствин обпдеизмковои спецификации (CLS) он дол- 
жен прнмо или косвенно наследоватћ от абстрактного класса System. Attnibute. 
В C# допустимм толбко CLS -совместимме атрибутм. В документации на .NET 
Framework SDK можно обнаружитБ определенин следукицих классов из предћвду- 
вдего примера: StnuctLayoutAttnibute, ManshalAsAttnibute,DllImpontAttnibute, 
InAttnibute и OutAttnibute. Bce они находнтсн в пространстве имен System. 
Runtime . IntenopSenvices, при зтом классБ 1 атрибутов могут определитвси в лгобом 
пространстве имен. Можно заметитв, что все перечисленнвге классБ 1 нвлнготси произ- 
воднбши от класса System . Attnibute, как и положено CLS -совместимБш атрибутам. 

ПРИМЕЧАНИЕ 

При определении атрибута компиллтор позволлет опускатБ суффикс Attribute, что 
упроидает ввод кода и делает его более читабелБнмм. 9 \ активно исполБзукз зту воз- 
можностб в приводиммх в книге примерах — например, пишу [Dlllmport( ...)] вместо 
[DlllmportAttribute(. ..)]. 


Как уже упоминалосБ, атрибутБг ивлиготси зкземплирами класса. И зтот класс 
должен иметв открБгтБги конструктор длл созданин зкземпллров. А значит, синтаксис 
примененин атрибутов аналогичен ввгзову конструктора. Кроме того, исполвзуемБпт 
ИЗБ1К может поддерживатБ специалБНБш синтаксис определенгш открБггБгх полеи 
или своиств класса атрибутов. Рассмотрим зто на примере. Вернемсн к приложениго, 
в котором атрибут Dlllmpont примениетси к методу GetVensionEx: 

[DllImportC’KernelB^", CharSet = CharSet . Auto, SetLastError = true)] 

Вбгглидит доволбно странно, но врнд ли bbi будете когда-нибудв исполбзо- 
ватБ подобнБ 1 и синтаксис дли вБгзова конструктора. Согласно описаниго класса 
DllImpontAttnibute в документации, его конструктор требует единственного па- 
раметра типа Stning. В рассматриваемом примере в качестве параметра передаетси 
строка "Kennel32". ПараметрБ 1 конструктора назвшаготсн позиционтши (positional 
parameters); при применении атрибута следует обизателБно их указишатБ. 

А что с егце двуми «параметрами»? Показаннвш осо 6 б 1 и синтаксис позволиет 
задаватв лгобБ1е открБ1ТБ1е полн или своиства обвекта DllImpontAttnibute после его 
создании. В рассматриваемом примере при создании зтого обвекта его конструк- 
тору передаетси строка "Kennel32", а otkpbitbim зкземплирнБш полим ChanSet 
и SetLastEnnon присваиваготси значенин ChanSet.Auto и tnue соответственно. 
«Параметрв 1 », задагогцие полн или своиства, назБгваготсн именованними (named 
parameters); они нвлнготси необнзателвнБши. ЧутБ позже мб 1 рассмотрим, как ини- 
циироватБ конструирование зкземплнра класса DllImpontAttnibute. 

Следует заметитв, что к одному злементу можно применитв несколБКО атри- 
бутов. Скажем, в приведенном в начале главБ 1 фрагменте кода к параметру ven 
метода GetVensionEx примениготси атрибутБ 1 In и Out. Учтите, что порндок следо- 
вангш атрибутов в такои ситуации не имеет значенгш. В C# отделБнвге атрибутБ 1 
могут заклгочатБСи в квадратнвге скобки; также возможно перечисление наборов 
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атрибутов в зтих скобках через запнтуго. Если конструктор класса атрибута не 
имеет параметров, круглме скобки можно опуститм Ну и, как уже упоминалосБ, 
суффикс Attnibute также ивлнетсл необнзателБншм. Показаннше далее строки 
приводлт к одному и тому же резу.њтату и демонстриругот все возможнме способм 
примененгш набора атрибутов: 

[Serializable][Flags] 

[Serializable, Flags] 

[FlagsAttributej SerializableAttribute] 

[FlagsAttribute()][Serializable()] 


Определение класса атрибутов 

Вм уже знаете, что лгобои атрибут представлиет собои зкземплнр класса, производ- 
ного от System.Attribute, и умеете применнтБ атрибутБг Пришло времн рассмо- 
третв процесс их создангш. Представнте, что вбг работаете в Microsoft и получили 
задание реализоватв поддержку битовкгх флагов в перечислимвгх типах. Длн начала 
нужно определитБ класс FlagsAttribute: 

namespace System { 

public class FlagsAttribute : System.Attribute { 
public FlagsAttribute() { 

} 

} 

} 


Обратите внимание, что класс FlagsAttribute наследует от класса Attribute; 
именно зто делает его CLS -совместимБш. Вдобавок в имени класса присутствует 
суффикс Attribute. Зто соответствует стандарту именовангш, хоти и не нвлиетси 
обизателБНБш. Наконец, все неабстрактнвге атрибутБг должнбг содержатБ хоти 6бг 
один открБгтБш конструктор. Простеишии конструктор FlagsAttribute не имеет 
параметров и не ввшолниет никаких деиствии. 

ВНИМАНИЕ 

Атрибут следует рассматриватБ как логическии контеинер состолнил. Иначе гово- 
рл, хотл атрибут и лвллетсл классом, зтот класс должен битБ краине простмм. Он 
должен содержатБ всего один открБ 1 тми конструктор, принимакиции облзателБнукз 
(или позиционнукз) информацикз о состолнии атрибута. Также класс может содер- 
жатБ OTKpbiTbie полл/своиства, принимакзидие дополнителвнукз (или именованнукз) 
информацикз о состолнии атрибута. В классе не должно бмти открмтих методов, 
co6biTHH или других членов. 

В обидем случае л не одобрлкз исполвзование открмтмх полеи. Атрибутов зто тоже 
касаетсл. Лучше восполвзоватвсл своиствами, так как они обеспечивакзт 6onbmyio 
гибкостБ в случапх, когда требуетсл внести измененип в реализацикз класса атри- 
бутов. 
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Получаетсл, что зкземплирм класса FlagsAttnibute можно применнтБ к чему 
угодно, хотл реалћно зтот атрибут следует применнтБ толбко к перечислимБш ти- 
пам. Нет смБ1Сла применнтБ его к своиству или методу. 4to6bi указатБ компилнтору 
областБ деиствгш атрибута, применим к классу атрибута зкземплир класса Sy stem . 
AttnibuteUsageAttnibute: 

namespace System { 

[AttnibuteUsage(AttributeTargets.Enum, Inherited = false)] 
public class FlagsAttribute : System.Attribute { 
public FlagsAttribute() { 

} 

} 

} 


B зтои новои версии зкземплир AttnibuteUsageAttnibute применнетсл к атри- 
буту. В конце концов, атрибутБ 1 — зто всего лишб классБц а значит, к ним, в cboio 
очередв, можно применнтБ другие атрибутБг Атрибут AttnibuteUsage нвлнетсл 
проствш классом, указБшагогцим компилнтору областк деиствил настраиваемого 
атрибута. Все компиллторБ 1 имегот встроеннуго поддержку зтого атрибута и при 
попБ1тке применитБ его к недопустимому злементу вБвдагот сообгцение об ошибке. 
В рассматриваемом примере атрибут AttnibuteUsage указвгвает, что зкземплнрБг 
атрибута Flags работагот толбко с перечислимБши типами. 

Так как все атрибутвг нвллготсн типами, понптб, как устроен класс 
AttnibuteUsageAttnibute, несложно. Вот исходнбш код зтого класса в FCL: 

[Serializable] 

[AttributeUsage(AttributeTargets . Class, Inherited=true)] 
public sealed class AttributeUsageAttribute : Attribute { 

internal static AttributeUsageAttribute Default = 
new AttributeUsageAttribute(AttributeTargets.All); 

internal Boolean m_allowMultiple = false; 

internal AttributeTargets m_attributeTarget = AttributeTargets.All; 

internal Boolean m_inherited = true; 

// Единственнии откритии конструктор 

public AttributeUsageAttribute(AttributeTargets validOn) { 
m_attributeTarget = validOn; 

} 

internal AttributeUsageAttribute(AttributeTargets validOn, 

Boolean allowMultiple, Boolean inherited) { 
m_attributeTarget = validOn; 
m_allowMultiple = allowMultiple; 
m_inherited = inherited; 

} 

public Boolean AllowMultiple { 
get { return m_allowMultiple; } 
set { m_allowMultiple = value; } 

} 


продолжение & 
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public Boolean Inherited { 
get { return m_inherited; } 
set { m_inherited = value; } 

} 

public AttributeTargets ValidOn { 
get { return m_attributeTarget; } 

} 

} 


Как видите, класс AttributeUsageAttribute имеет открштми конструктор, 
которми позволнет передаватБ битовме флаги, обозначакпцие областБ примененин 
атрибута. Перечислимми тип System.AttributeTargets определнетсл в FCL так: 

[Flags, Serializable] 
public enum AttributeTargets { 

Assembly = 0x0001, 

Module = 0x0002, 

Class = 0x0004, 

Struct = 0x0008, 

Enum = 0x0010, 

Constructor = 0X0020, 

Method = 0x0040, 

Property = 0x0080, 

Field = 0x0100, 

Event = 0x0200, 

Interface = 0x0400, 

Parameter = 0x0800, 

Delegate = 0x1000, 

ReturnValue = 0x2000, 

GenericParameter = 0x4000, 

All = Assembly | Module | Class | Struct | Enum | 

Constructor | Method | Property | Field | Event | 

Interface | Parameter | Delegate | ReturnValue | 

GenericParameter 

} 


У класса AttributeUsageAttribute естБ два дополнителБнмх открмтмх свои- 
ства, котормм при применении атрибута к классу могут 6 мтб присвоенм значенин 

AllowMultiple и Inherited. 

Болбшинство атрибутов не имеет сммсла применнтБ к одному злементу более 
одного раза. Например, вам ничего не даст последователБное применение атрибута 

Flags или Serializable: 

[Flags][Flags] 
internal enum Color { 

Red 

} 

Более того, при попБ 1 тке компилнции такого кода понвитсн сообгцение об ошибке 
(ошибка CS0579: дублирование атрибута Flags): 

error CS0579: Duplicate 'Flags’ attribute 
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Однако естБ и атрибутБ 1 , многократное применение которБ 1 х оправдано — в FCL 
зто класс атрибутов ConditionalAttnibute. Длн зтого параметру AllowMultiple 
должно 6 б 1 тб присвоено значение tnue. В противном случае многократное при- 
менение атрибута невозможно. 

Своиство Inhenited класса AttnibuteUsageAttnibute указвшает, будет ли 
атрибут, примениемБш к базовому классу, применнтБСи также к производнБ1м 
классам и переопределеннБш методам. СутБ наследованин атрибута демонстрирует 
следугошии код: 

[AttnibuteUsage(AttributeTargets . Class | AttributeTargets.Method, 

Inherited=true) ] 

internal class TastyAttribute : Attribute { 

} 

[Tasty][Serializable] 
internal class BaseType { 

[Tasty] protected virtual void DoSomething() { } 

} 

internal class DerivedType : BaseType { 
protected override void DoSomething() { } 

} 

B зтом коде класс DenivedType и его метод DoSomething снабженБ 1 атрибутом 
Tasty, так как класс TastyAttnibute помечен как наследуемБш. При зтом класс 
DenivedType несериализуемБ 1 и, потому что класс SenializableAttnibute в FCL 
помечен как ненаследуемвш атрибут. 

Следует помнитб, что в .NET Framework наследование атрибутов допустимо 
толбко дли классов, методов, своиств, со 6 б 1 тии, полеи, возврагцаемБгх значении 
и параметров. Не забвшаите об зтом, присваиваи параметру Inhenited значение 
tnue. Кстати, при наличии наследуемвш атрибутов дополнителвнБге метаданнБге 
в управлиемБпг модулБ длл производнБ 1 х типов не добавлнготси. Более подробно 
мб 1 поговорим об зтом чутв по.зжс. 

ПРИМЕЧАНИЕ 

Если при определении собственного класса атрибутов bw забудете примениљ атрибут 
AttributeUsage, компиллтор и CLR будут рассматриватБ полученнми резулвтат как при- 
менимБ 1 и к лкзбмм злементам, нотолбко один раз. Крометого, он будетнаследуеммм. 
Именно такие значенин по умолчанико имекот полл класса AttributeUsageAttribute. 


Конструктор атрибута и типм даннБ1х 
полеи и своиств 


Определни класс настраиваемБ 1 х атрибутов, можно указатв конструктор с параме- 
трами, которБ1е должен задаватн разработчик, исполБзугогции зкземплнр атрибута. 
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Кроме того, вм можете определитБ нестатические открмтме полн и своиства своего 
типа, которме разработчик может задаватБ по желаниго. 

Определнн конструктор зкземплнров класса атрибутов, а также полн и своиства, 
следует ограничитБСи неболБшим набором типов даннБ 1 х. ДопустимБ 1 типбк Bool- 
ean, Chan, Byte, SByte, Intl6, UIntl6, Int32, UInt32, Int64, UInt64, Single, Double, 
Stning, Туре, Ob ject и перечислимБге типбт Можно исполБЗОватБ также одномернБге 
массивБ1 зтих типов с нулевои нижнеи границеи, но зто не рекомендуетсл, так как 
класс настраиваемБ1х атрибутов, конструктор которого умеет работатБ с массивами, 
не относитси к CLS -совместимБш. 

Примении атрибут, следует указБшатБ определенное при компилнции постонн- 
ное вБ 1 ражение, совпадагогцее с типом, заданнБш классом атрибута. Каждвш раз, 
когда класс атрибута определлет параметр, поле или своиство типа Туре, следует 
исполвзоватБ оператор typeof изБша С#, как показано в следугогцем фрагменте 
кода. А длл параметров, полеи и своиств типа Ob ject можно передаватв значенгш 
типа Int32, Stning и другие постонннбш вБфаженип (в том числе null). Если по- 
стоннное ввфажение принадлежит к значимому типу, зтот тип будет упакован при 
создании зкземплира атрибута. 

Пример примененгш атрибута: 

using System; 

internal enum Color { Red } 

[Attributellsage(AttributeTargets. All) ] 
internal sealed class SomeAttribute : Attribute { 

public SomeAttribute(String name, Object o, Type[] types) { 

// 'name' сшлаетси на String 

// 'o' сшлаетсл на один из легалБних типов (упаковка при необходимости) 

// 'types' ссмлаетсв на одномернми массив Types 
// с нулевои нижнеи границеи 

} 

} 

[Some("Teff" , Color.Red, new Type[] { typeof(Math), typeof(Console) })] 
internal sealed class SomeType { 

} 

Обнаружив настраиваемБш атрибут, компилптор создает зкземплпр класса 
зтого атрибута, передаваи его конструктору все указаннвге параметрвк Затем он 
присваивает значенгш открБ 1 твш полим и своиствам, исполвзун дли зтого усовер- 
шенствованнБ 1 и синтаксис конструктора. Инициализировав обвект настраиваемого 
атрибута, компиллтор сериализует его и сохраниет в таблице метаданшлх. 

ВНИМАНИЕ 

НастраиваемБ1и атрибут лучше всего представллтБ себе как зкземпллр класса, се- 
риализованнБ1и в баитовБ1и поток, находлидиисл в метаданнБ1х. В период вшполненил 
баитБ! из метаданнмх десериализукзтсл длл конструированил зкземпллра класса. 
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На самом деле компиллтор генерирует информацииз, необходимукз длл созданил 
зкземпллра класса атрибутов, и размеидает ее в метаданнмх. Каждвм параметр кон- 
структора записмваетсл с однобаитнв1м идентификатором, за котормм следуетего 
значение. Завершив «сериализацик)» параметров, компиллтор генерирует значенил 
длл каждого указанного полл и своиства, записмвал его имл, за котормм следует 
однобаитнвш идентификатор типа и значение. Длл массивов сначала указмваетсл 
количество злементов. 


Вћ»швление настраиваеммх атрибутов 

Само по себе определение атрибутов бесполезно. Вм можете определитБ лгобои 
класс атрибута и применитБ его в произволБном месте, но зто приведет толбко к по- 
нвлениго в вашеи сборке дополнителБНБгх метаданнћгх, никак не влиин на работу 
приложенин. 

Как показано в главе 15, применение к перечислимому типу System. Enum 
атрибута Flags меннет поведение его методов ToString и Format. Причинои зто- 
му нвлиетсл происходлгцаи во времи ввшолнешш проверка, не свизан ли атрибут 
Flags с перечислимБш типом, с которнш работагот даншле методБг. Код может 
анализироватБСи на наличие атрибутов при помогци технологии, назвшаемои orn- 
ражением (reflection). Подробно она рассматриваетсл в главе 23, здесв же н толбко 
продемонстрируго ее применение. 

Если 6 бг вб 1 6 бши разработчиком из Microsoft, которому поручено реализоватБ 
метод Format типа Enum, вбг 6бг сделали зто примерно так: 

public override String ToStringO { 

// Применлетсл ли к перечислимому типу зкземпллр типа FlagsAttribute? 
if (this.GetType( ). IsDefined(typeof(FlagsAttribute) , false)) { 

// Да; виполнлем код, интерпретиругации значение как 
// перечислимми тип с битовмми флагами 

} else { 

// Нет; вмполннем код, интерпретирунлции значение как 
// обичнии перечислимми тип 


} 

} 

Зтот код обрагцаетсл к методу IsDefined типа Туре, заставллн систему по- 
смотретв метаданнБге зтого перечислимого типа и определитБ, свизан ли с ним 
зкземшшр класса FlagsAttribute. Если метод IsDefined возврагцает значение 
true, значит, зкземшшр FlagsAttribute свнзан с перечислимвш типом, и метод 
Format будет считатн, что переданное значение содержит набор битовнгх флагов. 
В противном случае переданное значение будет восприниматБСл как о6бшнбш 
перечислимБш тип. 
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То естћ после определенин собственнБ1х классов атрибутов нужно также напи- 
сатБ код, провернкшдии, сушествует ли зкземплнр класса атрибута (длл указаннБ 1 Х 
злементов), и в зависимости от резулвтата меннкшдии порндок вБшолненин про- 
граммБк Толбко в зтом случае настраиваемвш атрибут принесет полнзу! 

ПроверитБ наличие атрибута в FCL можно разнвши способами. Длл обвектов 
класса System. Туре можноисполвзоватБметод IsDefined, какпоказаноранее. Но 
иногда требуетсн проверитБ наличие атрибута не длн типа, а длн сборки, модулн или 
метода. Остановимсн на методах класса System.Reflection.CustomAttnibute- 
Extensions. Именно он нвлнетсн базоввш длн CLS-coBMecnmn>ix атрибутов. В зтом 
классе длл полученгш атрибутов имеготсл три статических метода: IsDefined, 
GetCustomAttnibutes и GetCustomAttnibute. Каждвш из них имеет несколБКО 
перегруженнБ 1 х версии. К примеру, одна версгш каждого из методов работает с чле- 
нами типа (классами, структурами, перечислешшми, интерфеисами, делегатами, 
конструкторами, методами, своиствами, полими, собвгтилми и возврагцаемБши 
типами), параметрами и сборками. Также сугцествугот версии, позволнгогцие про- 
сматриватБ иерархиго наследовангш и вклгочатв в резулвтат наследуемБге атрибутБГ. 
Краткое описание методов дано в табл. 18.1. 


Таблица 18 . 1 . МетодБ! класса System.Reflection.CustomAttributeExtensions, 
определлкзш,ие наличие в метаданннх CLS-coBMecTHMbix 
настраиваемнх атрибутов 


Метод 

Описание 

IsDefined 

Возврагцает значение true при наличии хотл бм одного зкзем- 
плнра указанного класса, производного от Attribute, свлзанного 
с целћго. Работает бмстро, так как не создает (не десериализует) 
никаких зкземпллров класса атрибута 

Get Custom Attributes 

Возврагцает массив, каждвги злемент которого лвллетсл зк- 
земплнром указанного класса атрибута. Каждми зкземплнр 
создаетсл (десериализуетсн) с исполвзованием указаннг>гх при 
компиллции параметров, полеи и своиств. Если целв не имеет 
зкземплнров указанного класса атрибута, метод возврагцает 
пустуго коллекцшо. Обмчно метод исполвзуетсн с атрибутами, 
параметр AllowMultiple которих имеет значение true, или со 
списком всех примененнвгх атрибутов 

Get Custom Attribute 

Возврагцает зкземплнр указанного класса атрибута. Каждми 
зкземшшр создаетсн (десериализуетсл) с исполвзованием 
указаннмх при компиллции параметров, полеи и своиств. 

Если целв не имеет зкземшшров указанного класса атри- 
бута, метод возврагцает null. При наличии более чем одного 
зкземшшра генерируетсл исклгочение System.Reflection. 
AmbiguousMatchException. 06бгчно метод работает с атрибута- 
ми, параметр AllowMultiple которнгх имеет значение false 
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Если нужно установитБ толбко сам факт примепепии атрибута, исполБзуите 
метод IsDefined как самкпт бБ 1 СтрБ 1 и из перечисленнБ 1 х. Однако при применении 
атрибута, как известно, можно задаватв параметрБ1 его конструктору и при необхо- 
димости определнтБ своиства и поли, а зтого метод IsDef ined делатв не умеет. 

Длл создании обвектов атрибутов исполвзуите метод GetCustomAttnibutes 
или GetCustomAttnibute. При каждом вБ130ве зтих методов создаготсн зкземплнрБ 1 
указаннБ 1 х классов атрибутов, и на основе указаннБ 1 х в исходном коде значении 
задаготсн полн и своиства каждого зкземплнра. Зти методБ 1 возврагцагот ссбшки на 
сконструированнБге зкземплнрБг классов атрибутов. 

Зти методвг просматривагот даннвге управлиемого модули и сравнивагот стро- 
ки в поиске указанного класса настраиваемого атрибута. Зти операции требугот 
времени, позтому если вас волнует бвгстродеиствие, подумаите о кзшировании 
резулвтатов работвг методов. В зтом случае вам не придетсл вБгзвшатБ их раз за 
разом, запрашиваи одну и ту же информациго. 

В пространстве имен System . Ref lection находнтсл к. /iaccbi, позволнгогцие ана- 
лизироватБ содержимое метаданнБгх модулп: Assembly, Module, Panametenlnfo, 
Membenlnfo, Туре, Methodlnfo, Constnuctonlnfo,Fieldlnfo,Eventlnfo,PnopentyInfo 
ггсоответствугогциеим классвг *Builden. Все зти классБг содержат методБг IsDefined 
и GetCustomAttnibutes. 

Версип метода GetCustomAttnibutes, определеннаи в классах, свизаннвгх с от- 
ражением, возврагцает массив зкземплиров Object (Object[ ]) вместо массива 
зкземплиров типа Attnibute (Attnibute[ ]). Дело в том, что классвг, свпзаннБге 
с отражением, могут возврагцатБ обвектБг из классов атрибута, не соответствугогцих 
спецификации CLS. К счаствго, такие атрибуткг встречаготсл краине редко. За все 
времн моеи работвг с .NET Framework п не сталкивалси с ними нгг разу. 

ПРИМЕЧАНИЕ 

Имеите в виду, что методм отражениа, noAaep^HBaiOLune логическии параметр inherit, 
реализунзттолБко классм Attribute, Туре и Methodlnfo. Все прочие методм отраженил 
зтот параметр игнорирунзт и иерархикз наследованил не проверл10т. Длч проверки 
наличич унаследованного атрибута в собБ1тилх, своиствах, поллх, конструкторах или 
параметрах исполБзуите один из методов класса Attribute. 

Естб егце один аспект, о котором следует помнитб. После передачи класса ме- 
тодам IsDefined, GetCustomAttnibute или GetCustomAttnibutes онгг начинагот 
искатБ зтот класс атрибута или производнБге от него. Длп поиска конкретного 
класса атрибута требуетси дополнителБнап проверка возврагценного значентш, 
котораи гарантирует, что возврагцен именно тот класс, которвш вам нужен. Чтобвг 
избежатв недоразуменгш и дополнителБНБгх проверок, можно определитв класс 
с модификатором sealed. 

Вот пример рассмотрешш методов внутргг тггпа и отображенин применпемБгх 
к каждому ггх методов атрибутов. Зто демонстрационнБш код; обкгчно никто не 
прггменпет указаннкге настраиваемБге атрибутБг подо6нбгм образом: 
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using System; 

using System.Diagnostics; 

using System.Reflection; 

[assembly: CLSCompliant(true)] 

[Serializable] 

[DefaultMemberAttribute("Main")] 

[DebuggerDisplayAttribute("Richter", Name = "leff", 

Target = typeof(Program))] 
public sealed class Program { 

[Conditional("Debug")] 

[Conditional("Release")] 
public void DoSomething() { } 

public Program() { 

} 

[CLSCompliant(true)] 

[STAThread] 

public static void Main() { 

// Вмвод набора атрибутов, примененних к типу 
ShowAttributes(typeof(Program) ); 

// Получение и задание методов, свлзанних с типом 
var members = 

from m in typeof(Program).GetTypeInfo().DeclaredMembers.OfType<MethodBase>() 
where m.IsPublic 
select m; 

foreach (Memberlnfo member in members) { 

// Вмвод набора атрибутов, примененнмх к члену 
ShowAttributes(member) ; 

} 

} 

private static void ShowAttributes(MemberInfo attributeTarget) { 
var attributes = attributeTarget.GetCustomAttributes<Attribute>(); 

Console.WriteLine("Attributes applied to {0}: {1}", 

attributeTarget.Name, (attributes.Count() == 0 ? "None" : String.Empty)); 

foreach (Attribute attribute in attributes) { 

// Вмвод типа всех примененнмх атрибутов 
Console.WriteLine(" {0}", attribute.GetType() .ToStringO); 

if (attribute is DefaultMemberAttribute) 

Console.WriteLine(" MemberName={0}", 

((DefaultMemberAttribute) attribute).MemberName); 


if (attribute is ConditionalAttribute) 
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Console.WriteLine(" ConditionString={0 }" , 

( (ConditionalAttribute) attribute).ConditionString); 

if (attribute is CLSCompliantAttribute) 

Console.WriteLine(" IsCompliant={0}", 

((CLSCompliantAttribute) attribute).IsCompliant); 

DebuggerDisplayAttribute dda = attribute as DebuggerDisplayAttribute; 
if (dda != null) { 

Console.WriteLine(" Value={0}j Name={l}, Target={2}", 
dda.Value, dda.Name, dda.Target); 

} 

} 

Console.WriteLine(); 

} 

} 


Скомпоновав и запустив зто приложение, мм получим слсдутотции резулћтат: 

Attributes applied to Program: 

System.SerializableAttribute 
System.Diagnostics.DebuggerDisplayAttribute 
Value=Richter, Name=leff, Target=Program 
System.Reflection.DefaultMemberAttribute 
MemberName=Main 

Attributes applied to DoSomething: 

System.Diagnostics.ConditionalAttribute 
ConditionString=Release 
System.Diagnostics.ConditionalAttribute 
ConditionString=Debug 

Attributes applied to Main: 

System.CLSCompliantAttribute 
IsCompliant=True 
System.STAThreadAttribute 

Attributes applied to .ctor: None 


Сравнение зкземпллров атрибута 

Tenepb, когда вм умеете находитБ зкземплирм атрибутов в коде, имеет сммсл рас- 
смотретБ процедуру проверки значении, храннгцихсн в их полнх. Можно, к примеру, 
написатБ код, нвнмм образом провернклции значение каждого полн класса атрибута. 
Однако класс System.Attribute переопределлет метод Equals класса Object, за- 
ставлии его сравниватБ типм обЂектов. Если они не совпадагот, метод возврагцает 
значение f alse. В случае же совпадентш метод Equals исполБзует отраженгш длн 
сравненгш полеи двух атрибутов (вмзмваи метод Equals длл каждого поли). Если 
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все полн совпадагот, возврашаетсл значение tnue. Можно переопределитБ метод 
Equals в вашем собственном классе атрибутов, убрав из него отраженин и повбгсив 
тем самБ1м производителБностБ. 

Класс System . Attnibute содержит также виртуалБНБш метод Match, которБш 
вб 1 можете переопределитБ длн полученин более богатои семантики. По умолчаниго 
даннБш метод просто вБИБшает метод Equals и возврагцает полученнвш резулБтат. 
Следугогции код демонстрирует переопределение методов Equals и Match (значение 
tnue возврагцаетсн, если один атрибут представлнет собои подмножество другого) 
и применение второго из них: 

using System; 

[Flags] 

internal enum Accounts { 

Savings = 0x0001, 

Checking = 0x0002, 

Bnokerage = 0x0004 

} 

[AttributeUsage(AttributeTargets. Class)] 
internal sealed class AccountsAttribute : Attribute { 
private Accounts m_accounts; 

public AccountsAttribute(Accounts accounts) { 
m_accounts = accounts; 

} 

public override Boolean Match(Object obj) { 

// Если в базовом классе реализован метод Match и зто не 
// класс Attribute, раскомментируите следунлцут строку 
// if (! base.Match(obj) ) return false; 

// Так как ’this' не равен null, если obj равен null, 

// o6beKTbi не совпадакгг 

// ПРИМЕЧАНИЕ. Зту строку можно удалитБ, если bn считаете, 

// что базовми тип корректно реализует метод Match 
if (obj == null) return false; 

// OČbeKTbl pa3HblX ТИПОВ Не МОГуТ 6blTb paBHbl 

// ПРИМЕЧАНИЕ . Зту строку можно удалити, если bn считаете, 

// что базовни тип корректно реализует метод Match 
if (this.GetType() != obj.GetType( )) return false; 

// Приведение obj к нашему типу длл доступа к поллм 
// ПРИМЕЧАНИЕ. Зто приведение всегда работает, 

// так как об^ектш принадлежат к одному типу 
AccountsAttribute other = (AccountsAttribute) obj; 

// Сравнение полеи 

// Проверка, лвллетсл ли accounts 'this' подмножеством 
// accounts обиекта others 

if ( (other.m_accounts & m_accounts) != m_accounts) 
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return false; 

return true; // ОбБектн совпадаит 

} 

public override Boolean Equals(Object obj) { 

// Если в базовом классе реализован метод Equals и зто 
// не класс Object, раскомментируите следунлцук) строку 
// if (! base . Equals(obj) ) return false; 

// Так как 'this' не равен null, при obj равном null 
// обнек™ не совпадак)т 

// ПРИМЕЧАНИЕ. Зту строку можно удалити, если вн считаете, 

// что базовни тип корректно реализует метод Equals 
if (obj == null) return false; 

// Обиектн разннх типов не могут совпасти 

// ПРИМЕЧАНИЕ. Зту строку можно удалити, если вн считаете, 

// что базовни тип корректно реализует метод Equals 
if (this.GetType() != obj.GetType()) return false; 

// Приведение obj к нашему типу длл полученил доступа к полпм 
// ПРИМЕЧАНИЕ. Зто приведение работает всегда, 

// так как об^ектм принадлежат к одному типу 
AccountsAttribute other = (AccountsAttribute) obj; 

// Сравнение значении полеи 'this' и other 
if (other.m_accounts != m_accounts) 
return false; 

return true; // Обиектш совпадашт 

} 

// Переопределлем GetHashCode, так как Equals уже переопределен 
public override Int32 GetHashCode() { 
return (Int32) m_accounts; 

} 

} 

[Accounts(Accounts.Savings)] 
internal sealed class ChildAccount { } 

[Accounts(Accounts.Savings | Accounts.Checking | Accounts.Brokerage)] 
internal sealed class AdultAccount { } 

public sealed class Program { 
public static void Main() { 

CanWriteCheck(new ChildAccount()); 

CanWriteCheck(new AdultAccount()); 

// Просто длп демонстрации корректности работш метода длн 
// типа, к которому не бшл применен атрибут AccountsAttribute 


продолжение & 
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CanWriteCheck(new Program()); 

} 

private static void CanWriteCheck(Object obj) { 

// Создание и инициализациа зкземпллра типа атрибута 
Attribute checking = new AccountsAttribute(Accounts.Checking); 

// Создание зкземпллра атрибута, примененного к типу 
Attribute validAccounts = 

obj.GetType().GetCustomAttribute<AccountsAttribute>(false); 

// Если атрибут применен к типу и указувает на счет "Checking", 

// значит, тип может виписшатц чеки 

if ( (validAccounts != null) && checking.Match(validAccounts) ) { 
Console.WriteLine("{0} types can write checks.", obj.GetType()); 

} else { 

Console.WriteLine("{0} types can NOT write checks.", obj.GetType()); 

> 

} 


Построение и запуск зтого приложенин приводит к следугогцему резу.тптату: 

ChildAccount types can NOT write checks. 

AdultAccount types can write checks. 

Program types can NOT write checks. 


Вшлвление настраиваеммх 
атрибутов без созданив обг»ектов, 
производнмх от Attribute 

В зтом разделе мм поговорим об алБтернативном способе вБ1нвлен1ш настраи- 
ваемБ1х атрибутов, примененнБ1х к метаданнБш. В ситуацинх, требугогцих повбн 
шеннои безопасности, зтот способ гарантированно предотврагцает ввшолнение 
кода класса, производного от Attribute. Вообгце говори, при вБ 130 ве методов 
GetCustomAttribute ( s ) типа Attribute вБ 13 Б 1 ваетсн конструктор класса атрибута 
и методБ1, задагогцие значенгш своиств. А первое обрагцение к типу заставлнет CLR 
вБгзватв конструктор зтого типа (если он, конечно, сугцествует). Конструктор, метод 
доступа set и методвг конструктора типа могут содержатн код, вбшолннгогцииси 
при каждом поиске атрибута. Возможностб вБшолненгш в домене приложенгш не- 
известного кода создает потенциалвнуго угрозу безопасности. 

Длн обнаруженгш атрибутов без ввшолненгш кода класса атрибута применнетсн 
класс System.Reflection.CustomAttributeData. В нем определен единственнБШ 
статическии метод GetCustomAttributes, позволнгогции получитв информациго 
о примененнБгх атрибутах. Зтот метод имеет четБгре перегруженнБге версии: одна 
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принимает параметр типа Assembly, другал — Module, третћн — Parameterlnf о, по- 
следннн — Memberlnfo. Классопределен в пространствеимен System.Reflection, 
о котором будет рассказано в главе 23. Обмчно класс CustomAttributeData ис- 
полБзуетсл длл анализа метаданнмх сборки, загружаемои статическим методом 
ReflectionOnlyLoad класса Assembly (он также рассматриваетси в главе 23). Пока 
же достаточно сказатБ, что зтот метод загружает сборку таким образом, что CLR не 
может вбшолннтб какои-либо код, в том числе конструкторБ 1 типов. 

Метод GetCustomAttributes класса CustomAttributeData работает как ме- 
тод-фабрика: он возврашает набор обвектов CustomAttributeData в обвекте типа 
IList<CustomAttributeData>. Каждому злементу зтои коллекции соответствует 
один настраиваемБш атрибут. Длн каждого обвекта класса CustomAttributeData 
можно запроситБ предназначеннБ1е толбко дли чтенгш своиства, определив в ре- 
зулвтате, каким способом мог би бигпЂ сконструирован и инициализирован обвект. 
Например, своиство Constructor указвшает, какои именно конструктор мог би бигпЂ 
вБгзван. Своиство ConstructorArguments возврагцает аргументм, которвге могли би 
бигпЂ переданБг конструктору в качестве зкземплнра IList<CustomAttributeTyped 
Argument>. Своиство NamedArguments возврагцает полн и своиства, которвге могли 
би 6umb заданвг как зкземплнр IList<CustomAttributeNamedArgument>. Условное 
наклонение во всех зтих предложенгшх обусловлено тем, что ни конструктор, ни 
метод доступа set на самом деле не вБгзвгваготсл. Дли безопасности запрегцено вбг- 
полнение лгобнгх методов класса атрибута. 

Ниже приведена измененнаи версин предвгдугцего кода, в которои дли безопас- 
ного полученгш атрибутов исполвзуетсц класс CustomAttributeData: 

using System; 

using System.Diagnostics; 

using System.Reflection; 

using System.Collections.Generic; 

[assembly: CLSCompliant(true)] 

[Serializable] 

[DefaultMemberAttribute("Main")] 

[DebuggerDisplayAttribute("Richter", Name="Deff", Target=typeof(Program))] 
public sealed class Program { 

[Conditional("Debug")] 

[Conditional("Release")] 
public void DoSomething() { } 

public Program() { 

} 

[CLSCompliant(true)] 

[STAThread] 

public static void Main() { 

// Вмвод атрибутов, примененнмх к данному типу 
ShowAttributes(typeof(Program) ); 


продолжение & 
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// Получение набора свлзанних с типом методов 

Memberlnfof] members = typeof(Program) . FindMembers( 
MemberTypes.Constructor | MemberTypes.Methodj 
BindingFlags.DeclaredOnly | BindingFlags.Instance | 
BindingFlags.Public | BindingFlags.Static, 

Туре .FilterNamej 

foreach (Memberlnfo member in members) { 

// Вувод атрибутов, примененнмх к данному члену 
ShowAttributes(member) ; 

} 


private static void ShowAttributes(MemberInfo attributeTarget) { 
IList<CustomAttributeData> attributes = 

CustomAttributeData.GetCustomAttributes(attributeTarget); 

Console.WriteLine("Attributes applied to {0}: {1}", 
attributeTarget.Name, ( 

attributes.Count == 0 ? "None" : String.Empty)); 

foreach (CustomAttributeData attribute in attributes) { 

// Вмвод типа каждого примененного атрибута 
Туре t = attribute.Constructor.DeclaringType; 

Console.WriteLine(" {0}"j t.ToString()); 

Console.WriteLine(" Constructor called={0}"j attribute.Constructor) 

IList<CustomAttributeTypedArgument> posArgs = 
attribute.ConstructorArguments; 

Console.WriteLine(" Positional arguments passed to constructor:" + 

((posArgs.Count == 0) ? " None" : String.Empty)); 
foreach (CustomAttributeTypedArgument pa in posArgs) { 
Console.WriteLine(" Type={0}, Value={l}"j 
pa.ArgumentType, pa.Value); 

} 

IList<CustomAttributeNamedArgument> namedArgs = 
attribute.NamedArguments; 

Console.WriteLine(" Named arguments set after construction:" + 
((namedArgs.Count == 0) ? " None" : String.Empty)); 
foreach(CustomAttributeNamedArgument na in namedArgs) { 
Console.WriteLine(" Name={@}j Туре={1} а Value={2}"j 
na.Memberlnfo.Name, na.TypedValue.ArgumentTypej 
na.TypedValue.Value); 

} 

Console.WriteLine(); 

} 

Console.WriteLine(); 

} 

} 
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Компоновка и запуск зтого приложенил приведут к следукицему резулкгату: 

Attributes applied to Program: 

System.SerializableAttribute 
Constructor called=Void .ctor() 

Positional arguments passed to constructor: None 
Named arguments set after construction: None 

System.Diagnostics.DebuggerDisplayAttribute 
Constructor called=Void .ctor(System.String) 

Positional arguments passed to constructor: 

Type=System.Stringj Value=Richter 
Named arguments set after construction: 

Name=Namej Type=System.Stringj Value=Deff 

Name=Target, Type=System.Typej Value=Program 

System.Reflection.DefaultMemberAttribute 

Constructor called=Void .ctor(System.String) 

Positional arguments passed to constructor: 

Type=System.Stringj Value=Main 
Named arguments set after construction: None 

Attributes applied to DoSomething: 

System.Diagnostics.ConditionalAttribute 

Constructor called=Void .ctor(System.String) 

Positional arguments passed to constructor: 

Type=System.Stringj Value=Release 
Named arguments set after construction: None 

System.Diagnostics.ConditionalAttribute 

Constructor called=Void .ctor(System.String) 

Positional arguments passed to constructor: 

Type=System.Stringj Value=Debug 
Named arguments set after construction: None 

Attributes applied to Main: 

System.CLSCompliantAttribute 

Constructor called=Void .ctor(Boolean) 

Positional arguments passed to constructor: 

Type=System.Booleanj Value=True 
Named arguments set after construction: None 

System.STAThreadAttribute 

Constructor called=Void .ctor() 

Positional arguments passed to constructor: None 
Named arguments set after construction: None 


Attributes applied to .ctor: None 
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Условнне атрибутн 

Программистм все чагце исполБзугот атрибутм благодарл простоте их созданин, 
примененил и отраженгш. Атрибутм позволнгот также снабдитБ код аннотацинми, 
одновременно реализун другие богатне возможности. В последнее времн атрибутм 
часто исполБзуготсн при написании и отладке кода. Например, анализатор кода длн 
Microsoft Visual Studio (FxCopCmd.exe) предлагает атрибут System.Diagnostics . 
CodeAnalysis . SuppressMessageAttribute, применимБш к типам ичленам и пода- 
влпгогции сообгценин о нарушении правила определенного инструмента статического 
анализа. Зтот атрибут игцетсл толбко кодом анализатора, при нормалБном ходе 
вБшолненгш программБг он игнорируетсл. Если вбг не анализируете код, наличие 
в метадашшх атрибута SuppressMessage просто увеличивает обвем метаданнвгх, 
что не лучшим образом сказБшаетсл на производителБности. Соответственно, хо- 
телосв 6 б 1 , что 6 б 1 компилитор задеиствовал зтот атрибут толбко в случалх, когда 
вб1 собираетесБ восполБЗОватБСн инструментом анализа кода. 

Класс атрибута, к которому применен атрибут System.Diagnostics. 
ConditionalAttribute, назБшаетсл классом условного атрибута (conditional 
attribute). Пример: 

//#define TEST 
#define VERIFY 

using System; 

using System.Diagnostics; 

[Conditional("TEST")][Conditional("VERIFY")] 
public sealed class CondAttribute : Attribute { 

} 

[Cond] 

public sealed class Program { 
public static void Main() { 

Console.WriteLine("CondAttribute is {0}applied to Program type.", 

Attribute.IsDefined(typeof(Program), 
typeof(CondAttribute)) ? "" : "not "); 

} 

} 

Обнаружив, что 6 бш применен зкземплнр CondAttribute, компшштор помегцает 
в метаданнБге информациго об атрибуте, толбко если при компилнции кода 6 бш 
определен идентификатор TEST или VERIFY. При зтом метаданнБге определенгш 
и реализации класса атрибута все равно остапутси в сборке. 



Глава 19 . МиМ-совместимме 
значимне типш 


Как известно, переменнан значимого типа не может приниматБ значение null; ее 
содержимБш всегда ивлиетсл значение соответствугогцего типа. Именно позтому 
типб 1 и назБшагот значимими. Но в некоторБ 1 х ситуацилх такои подход создает про- 
блемБг Например, при проектировании базБ 1 даннБ 1 х тип даннБ 1 х столбца можно 
определитБ как 32-разрндное целое, что в FCL соответствует типу Int32. Однако 
в столбце базБ1 может отсутствоватБ значение, что соответствует значениго null, 
и зто — вполне стандартнаи ситуацин. А зто создаст проблемБ 1 при работе с базои 
даннБ 1 х средствами .NET Framework, ведв обгцеизБЖОван среда (CLR) не позволиет 
представитв значение типа Int32 как null. 

ПРИМЕЧАНИЕ 

Адаптерн таблиц MicrosoftADO.NET поддерживакггтипм, допускакзш,ие присвоение 
null. Но, ксожаленик), типб! в пространстве имен System.Data.SqlTypes не замеидакзт- 
сл пиП-совместиммми типами отчасти из-за отсутствил однозначного соответствил 
между ними. К примеру, тип SqlDecimal допускает максимум 38 разрлдов, в то времл 
как o6bi4Hbin тип Decimal — пуљко 29. А тип SqlString поддерживает собственнме 
pernoHanbHbie стандартм и порлдок сравненич, чего не скажеши о типе String. 


Вот егце один пример: в Java класс ј ava . util . Date относитсн к ссбглочнбш типам, 
а значит, его переменнБге допускагот присвоение значенин null. В то же времн в CLR 
тип System.DateTime нвлнетси значимвш и подобного присвоешш не допускает. 
Если написанному на Java приложениго потребуетсл передатв информациго о дате 
и времени веб-службе на платформе CLR, возможнбг проблемБг ВедБ если Java- 
приложение отправит значение null, CLR просто не будет знатв, что с ним делатБ. 

Что6бг исправитБ ситуациго, в Microsoft разработали дли CLR пиП-совместимие 
значимие типи (nullable value type). Чтобвг поннтб, как они работагот, познакомимсл 
с определеннБш в FCL классом System . Nullable<T>. Вот логическое представление 
реализации зтого класса: 

[Serializable, StructLayout(LayoutKind . Sequential) ] 
public struct Nullable<T> where T : struct { 

// Зти два полд представлв 10 т состовние 

private Boolean hasValue = falsej // Предполагаетсл наличие null 
internal T value = default(T); // Предполагаетсн, что все битм 

// равни нулго 
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public Nullable(T value) { 
this.value = value; 
this.hasValue = true; 

} 

public Boolean HasValue { get { return hasValue; } } 

public T Value { 
get { 

if (IhasValue) { 

throw new InvalidOperationException( 

"Nullable object must have a value."); 

} 

return value; 

} 


public T GetValueOrDefault() { return value; } 

public T GetValueOrDefault(T defaultValue) { 
if (IHasValue) return defaultValue; 
return value; 

} 

public override Boolean Equals(Object other) { 
if (IHasValue) return (other == null); 
if (other == null) return false; 
return value.Equals(other); 

} 

public override int GetHashCode() { 
if (IHasValue) return 0; 
return value.GetHashCode(); 

} 

public override string ToString() { 
if (IHasValue) return 
return value.ToString(); 

} 

public static implicit operator Nullable<T>(T value) { 
return new Nullable<T>(value); 

} 

public static explicit operator T(Nullable<T> value) { 
return value.Value; 

} 

} 


Как видите, зтот класс реализует значимми тип, которми может приниматћ значе- 
ние null. Так как Nullable<T > также относитсн к значиммм типам, его зкземплнрм 
достаточно производителБнм, посколБку зкземплнрм могут размегцатБСн в стеке, 
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а их размер совпадает с размером исходного типа, к которому приплгосован размер 
полн типа Boolean. Имеите в виду, что в качестве параметра Т типа Nullable могут 
исполвзоватБСн толбко структурБ1 — ведБ переменнБШ ссбшочного типа и так могут 
приниматБ значение null. 

Итак, что 6 б 1 исполБЗОватБ в коде null -совместимБш тип Int32, bhi пишете кон- 
струкцшо следугошего вида: 

Nullable<Int32> х = 5; 

Nullable<Int32> у = null; 

Console.WriteLine("x: HasValue={0}, Value={l}"j x.HasValue, x.Value); 
Console.WriteLine("y: HasValue={0}, Value={l}", 
у .HasValue, у .GetValueOrDefault()); 

После компилиции и запуска зтого кода будет получен следугогции резулвтат: 

х: HasValue=True, Value=5 
у: HasValue=False, Value=0 


Поддержка в C# пиМ-совместимнх 
значиммх типов 

В приведенном фрагменте кода длн инициализации двух переменнБ 1 х х и у типа 
Nullable<Int32> исполБзуетсл достаточно простои синтаксис. Дело в том, что раз- 
работчики C# старалисв интегрироватБ в избш пи11-совместимБ1е значимБ 1 е типбц 
сделав их полноправнвши членами соответствугогцего семеиства типов. В насточгцее 
времн C# предлагает достаточно удобнвш синтаксис длл работБ 1 с такими типами. 
I lepcMOiiiii.ie х и у можно о6ђнвитб и инициализироватБ примо в коде, восполбзо- 
вавшисв знаком вопроса: 

Int32? х = 5; 

Int32? у = null; 

В C# записв Int32? аналогична записи Nullable<Int32>. При зтом bhi можете 
вбшолннтб преобразовангш, а также приведение пи11-совместимБ1х зкземплиров к 
другим типам. Лзбш C# поддерживает возможностб примененгш операторов к зк- 
земплирам пи11-совместимБ1х значимБгх типов. Вот несколвко примеров. 

private static void ConversionsAndCastingO { 

// Неавное преобразование из типа Int32 в Nullable<Int32> 

Int32? а = 5; 

// Ненвное преобразование из 'null' в Nullable<Int32> 

Int32? b = null; 

// Лвное преобразование Nullable<Int32> в Int32 
Int32 c = (Int32) a; 


// Прнмое и обратное приведение примитивного типа 
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// в пи 11 -совместимми тип 

Double? d = 5; // Int32->Double? (d содержит 5.0 в виде double) 

Double? е = b; // Int32?->Double? (e содержит null) 

} 

Етце C# позволнет прпменптв операторм к зкземплнрам пи11-совместиммх типов. 

Вот iiecKo. iiiKo примеров: 

private static void Operators() { 

Int32? a = 5; 

Int32? b = null; 

// Унарнћ 1 е оператору (+ ++---! ~) 
a++; // a = 6 
b = -b; // b = null 

// Бинарнме оператору (+-*/% & | л << >>) 
а=а+3; //а=9 
b = b * 3; // b = null; 

// Оператори равенства (== !=) 
if (a == null) { /* нет */ } else { /* да */ } 

if (b == null) { /* да */ } else { /* нет */ } 

if (a != b) { /* да */ } else { /* нет */ } 

// Оператори сравненин (<> <= >=) 

if (a < b) { /* нет */ } else { /* да */ } 

} 

Вот как зти операторм интерпретирует С#: 

□ Унарнме операторм (+++, Если операнд равен null, резулктат тоже 

равен null. 

□ Бинарнме операторм (+, -, *, /, %, &, |, л , <<, >>). Резулвгатравензначеншо null, 
если зтому значеншо равен хотн 6bi один операнд. Исклгочением нвлнетсн случаи 
воздеиствин операторов & и | на логическии операнд ?. В резулћтате поведение 
зтих двух операторов совпадает с тернарнои логикои SQ.L. Если ни один из 
операндов не равен null, операцин проходит в обБганом режиме, если же оба 
операнда равни 1 null, в резулБтате получаем null. Особаи ситуацин возникает 
в случае, когда значениго null равен толбко один из операндов. В следугогцеи 
таблице показанБ1 возможнбго резулБтатБц которБге зти операторБ1 дагот длн всех 
возможнБ1Х комбинации значении true, falsennull. 

□ ОператорБГ равенства (==, !=). Если оба операнда имегот значение null, они 
равнБк Если толбко один из них имеет зто значение, операндБ 1 не равнБт Если 
ни один из них не равен null, операндБ 1 сравниваготсл на предмет равенства. 

□ OnepaTopbi сравненин (<, >, <=, >=). Если значение null имеет один из операн- 
дов, в резулБтате получаем значение f alse. Если ни один из операндов не имеет 
значенин null, следует сравнитБ их значении. 
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Операнд 1 -» 
Операнд 2 l 

true 

false 

null 

True 

& = true 

& = false 

& = null 


| = true 

| = true 

| = true 

False 

& = false 

& = false 

& = false 


| = true 

= false 

| = null 

Null 

& = null 

& = false 

& = null 


| = true 

| = null 

| = null 


Следует учестБ, что длл операции с зкземплирами пи11-совместимБ1х типов 
генерируетсн 6олбшои обвем кода. К примеру, рассмотрим метод: 

private static Int32? NullableCodeSize(Int32? a, Int32? b) { 
return a + b; 

} 

B резулБтате компиллции будет создан болкшои обвем IL -кода, вследствие 
чего операции с null -совместимБши типами вбшолннјотси медленнее аналогичнБ1х 
операции с другими типами. Вот зквивалент зтого кода на С#: 

private static Nullable<Int32> NullableCodeSize(Nullable<Int32> a, 

Nullable<Int32> b) { 

Nullable<Int32> nullablel = a; 

Nullable<Int32> nullable2 = b; 

if (!(nullablel.HasValue & nullable2.HasValue)) { 
return new Nullable<Int32>(); 

} 

return new Nullable<Int32>( 

nullablel.GetValueOrDefault() + nullable2.GetValue0rDefault()); 

} 

Напоследок напомнго o возможности определешш ваших co6ctbchhbix значимБ 1 х 
типов, перегружагоидих упомннутБ1е операторБк О том, как именно зто делаетсн, mki 
говорили в главе 8. Если восполБЗОватвси null -совместимБш зкземплиром вашего 
собственного значимого типа, компилитор поимет зто правилвно и вБШОвет пере- 
груженнБш оператор. Предположим, имеетсл значимБш тип Point, следугогцим 
образом определнкчции перегрузку операторов == и ! =: 

using System; 

internal struct Point { 
private Int32 m_x, m_y; 

public Point(Int32 х, Int32 у) { m_x = х; m_y = у; } 
public static Boolean operator==(Point pl, Point p2) { 

продолжение # 
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return (pl.m_x == p2.m_x) && (pl.m_y == p2.m_y); 

} 

public static Boolean operator!=(Point pl, Point p2) { 
return !(pl == p2); 

} 

} 

ВосполћзовавшисБ в зтот момент пи11-совместиммми зкземплнрами типа Point, 
вм заставите компилитор вмзватБ перегруженнме операторм: 

internal static class Program { 
public static void Main() { 

Point? pl = new Point(lj 1); 

Point? p2 = new Point(2j 2); 

Console.WriteLine("Are points equal? " + (pl == p2) .ToStringO); 
Console.WriteLine("Are points not equal? " + (pl != p2).ToStringO); 

} 


После запуска зтого кода и получил следуговдии резулшат: 

Are points equal? False 
Are points not equal? True 


Оператор обЂединенич 
пиМ-совместимБ1х значении 

В C# сушествует оператор обвединенил null -совместимих значенип (null-coalescing 
operator). Он обозначаетсл знаками ? ? и работает с двумн операндами. Если левми 
операнд не равен null, оператор возврагцает его значение. В противном случае воз- 
врагцаетсн значение правого операнда. Оператор обЂединенин null -совместиммх зна- 
чении удобен при задании предлагаемого по умолчаниго значенгш переменнои. 

Основнмм преимугцеством отого оператора нвлиетсл поддержка как ссмлоч- 
нмх, так и null -совместиммх значиммх типов. Следугогции код демонстрирует его 
работу: 

private static void NullCoalescingOperator( ) { 

Int32? b = null; 

// Приведеннал далее инструкцин зквивалентна следукицеи: 

// х = (b.HasValue) ? b.Value : 123 
Int32 х = b ?? 123; 

Console.WriteLine(x); // "123" 

// Приведеннал далее в инструкции строка зквивалентна следуклцему коду: 

// String temp = GetFilename( ); 
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// filename = (temp != null) ? temp : "Untitled"; 

String filename = GetFilename() ?? "Untitled"; 

} 

Некоторме полБЗОватели считагот оператор обЂединенил null -совместиммх 
значении всего лишђ синтаксическим сокрагцением длл оператора ?. Однако опе- 
ратор ? ? предоставлнет два важнмх синтаксических преимугцества. Во-первмх, он 
лучше работает с вмраженгшми: 

Func<String> f = () => SomeMethod() ?? "Untitled"; 

ПрочитатЂ и поннтђ зту строку намного прогце, чем следугогции фрагмент кода, 
требугогции присваивангш переменнмх и исполЂЗОвангш несколћких операторов: 

Func<String> f = () => { var temp = SomeMethod(); 
return temp != null ? temp : "Untitled";}; 

Во-втормх, оператор ? ? лучше работает в некотормх сложнмх ситуацгшх: 

String s = SomeMethodl( ) ?? SomeMethod2( ) ?? "Untitled"; 

СогласитесБ, зту строку прочитатБ и поннтб гораздо прогце, чем следугогции 
фрагмент кода: 

String s; 

var sml = SomeMethodl(); 
if (sml != null) s = sml; 
else { 

var sm2 = SomeMethod2(); 
if (sm2 != null) s = sm2; 
else s = "Untitled"; 

} 

Поддержка в CLR пиИ-совместимих 
значиммх типов 

В CLR сугцествует встроеннал поддержка пиП-совместимБгх значимБгх типов. 
Она предусматривает упаковку и распаковку, а также вбгзов метода GetType 
и интерфеиснБгх методов. Все зто призвано обеспечитв более теснуго интеграциго 
пи11-совместимБ1х значимБгх типов в CLR. В резулвтате типбг ведут себн более 
естественно и лучше соответствугот ожидангшм болвшинства разработчиков. Рас- 
смотрим поддержку зтих типов в CLR более подробно. 

Упаковка пиМ-совместиммх значиммх типов 

Представим переменнуго типа Nullable<Int32>, которои логически присваиваетси 
значение null. Длл передачи зтои переменнои методу, ожидагогцему ссбшки на 
тип Object, ее следует упаковатБ и передатБ методу ссБшку на упакованнБш тип 
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Nullable<Int32>. Однако при зтом в метод будет передано отличное от null значе- 
ние, несмотрн на то что тип Nullable<Int32> содержит null. Зта проблемарешаетсн 
в CLR при помотци специалБного кода, которми при упаковке null -совместиммх 
типов создает иллтозито их принадлежности к обмчнмм типам. 

При упаковке зкземплнра Nullable<T> проверлетсл его равенство null и в случае 
положителБного резулћтата вместо упаковки возврагцаетсл null. В противном случае 
CLR упаковвшает значение зкземплпра. Другими словами, тип Nullable<Int32> 
со значением 5 упаковвшаетсц в тип Int32 с аналогичнБш значением. Следугогции 
код демонстрирует такое поведение: 

// После упаковки Nullable<T> возврацаетсл null или упакованнми тип Т 
Int32? n = null; 

Object o = n; // o равно null 

Console.WriteLine("o is null={0}", o == null); // "True" 
n = 5; 

o = n; // o ссмлаетсл на упакованнми тип Int32 

Console . WriteLine("o ' s type={0}", o.GetType()); // "System.Int32" 


Распаковка пиМ-совместиммх значимих типов 

В CLR упакованнБпг значимБш тип Т распаковБшаетсл в Т или в Nullable<T >. Если 
ссвшка на упакованнБпг значимБпг тип равна null и вБшолннетсн распаковка в тип 
Nullable<T>, CLR присваивает Nullable<T> значение null. Пример: 

// Создание упакованного типа Int32 
Object о=5; 

// Распаковка зтого типа в Nullable<Int32> и в Int32 
Int32? а = (Int32?) о; // а = 5 
Int32 b = (Int32) о; // b = 5 

// Создание ссмлки, инициализированнои значением null 
о = null; 

// "Распаковка" ее в Nullable<Int32> и в Int32 
а = (Int32?) о; // а = null 
b = (Int32) о; // NullReferenceException 


Bbi 30 B метода GetType через пиП-совместимми 
значимми тип 

При ввгзове метода GetType длн обвекта типа Nullable<T> CLR возврагцает тип Т 
вместо Nullable<T>. Пример: 

Int32? х = 5; 

// Зта строка виводит "System.Int32", а не "System.Nullable<Int32>" 

Console . WriteLine(x . GetType( ) ); 
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Bbi 30 B интерфеиснмх методов через пиМ-совместимми 
значимми тип 


В приведенном далее фрагменте кода переменнан n типа Nullable<Int32> приво- 
дитснк интерфеисному типу IComparable<Int32>. Но тип Nullable<T> в отличие от 
типа Int32 не реализует интерфеис IComparable<Int32>. Тем не менее код успешно 
компилируетсн, а механизм верификации CLR считает, что код прошел проверку, 
чтобм вм могли исполБЗОватБ более удобнми синтаксис. 


Int32? n = 5; 

Int32 result = ((IComparable) n).CompareTo(5); 
Console.WriteLine(result); // 0 


// Компилируетсп 
// и внполнлетсл 


Без подобнои поддержки со сторонм CLR пришлосв бм писатБ громоздкии код 
вмзова интерфеисного метода через null -совместимми значимми тип. Длн вмзова 
метода потребовалосБ бм приведение распакованного значимого типа перед при- 
ведением к интерфеису: 

Int32 result = ( (IComparable) (Int32) n).CompareTo(5); // Громоздкии код 
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Зта глава посвишена обработке исклтченип (exception handling), хотл в неи будут 
затронутм и другие темм. Процесс обработки исклгоченгш состоит из несколБКих 
шагов. Дли начала следует определитБ, что именно считатБ ошибкои. После зтого 
нужно вмиснитб, когда возникает ошибка, и решитг>, как от нее избавитћсн. На зтом 
зтапе возникает вопрос о состоинии системм, так как ошибки обмчно возникагот 
в самое неподходнгцее времн. Скорее всего, ваш код в зтот момент будет находитћсн 
в некоем переходном состоинии и вам потребуетсн вернутБ его в состонние, су- 
гцествовавшее до возникновенин ошибки. Разумеетси, мм также вмнсним, каким 
образом код дает поннтг> о том, что с ним что-то не так. 

На Moii взгллд, обработка исклгочешш нвлиетсл саммм слабмм местом CLR, 
и именно позтому разработчикам бмвает так трудно писатг. управлнемми код. 
В последнее времи специалистм Microsoft внесли значителБнме улучшенин в зтот 
аспект, но до хорошеи, надежнои системм все егце достаточно далеко. О том, что 
именно бмло сделано в данном направлении, мм поговорим при рассмотрении не- 
обработаннмх исклгочении, областеи ограниченного вмполненгш, контрактов кода, 
средств создангш оберток дл и исклгочении во времн вмполненгш, неперехваченнмх 
исклгочении и т. п. 


Определение «исклк)ченил» 

Конструирун тип, мм заранее пмтаемси представитг., в каких ситуацгшх он будет 
исполБЗОватћси. В качестве имени типа обвгчно ввгбираетсн сугцествителБное, на- 
пример FileStream или StringBuilder. Затемзадаготси своиства, собвгтин, методвг 
и т. п. Форма определешш зтихчленов (типбг даннБгх своиств, параметрвг методов, 
возврагцаемБге значенгш и т. п.) становитсн программнвш интерфеисом типа. Именно 
членБг определнгот допустимБге деиствгш с типом и его зкземплнрами. Дли их имен 
обвгчно вБгбираготсн глаголБг, например Read, Write, Flush, Append, Insert, Remove 
и т. п. Если член не может решитн возложеннуго на него задачу, программа должна 
вБгдатв исклгочение. Рассмотрим следугогцее определение класса: 

internal sealed class Account { 

public static void Transfer(Account from, Account to^ Decimal amount) { 
from -= amount; 
to += amount; 

} 


} 
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Метод Т ransfer принимает два обвекта Account и значение Decimal, определнн, 
сколбко средств переводитсн с одного счета на другои. Очевидно, что зтот метод 
должен вшчитатБ денБги с одного счета и прибавлнтћ их к другому. Но естћ рнд 
обстоителћств, которвш могут помешатБ его работе. Например, аргумент f rom или 
to может имстб значение null; аргументБ1 f rom или to могут не соответствоватБ 
открБ1ТБ1м счетам; на счету, с которого предполагаетси взнтб дснбги, может оказатБ- 
сн недостаточно средств; на целевом счету может оказатвсн так много денег, что 
перевод дополнителвнои суммБ1 станет причинои переполненгш; аргумент amount 
может 6 б1тб равен 0, иметв отрицателБное значение или иметн более двух знаков 
после запитои. 

При вБгзове метода Transfer следует учитвшатБ все перечисленнБге ситуации 
и при вБшвлении лгобои из них оповегцатв вБИБшакзгции код, генерирул исклгочение. 
Обратите внимание, что возврагцаемое методом значение принадлежит к типу void. 
То еств метод Transf er просто завершает cboio работу, если завершение происходит 
в обвгчном режиме, или генерирует исклгочение в противном случае. 

ОбБектно-ориентированное программирование обеспечивает вБгсокуго зффек- 
тивностб труда разработчиков, так как позволлет писатв, например, такои код: 

Boolean f = "Deff " .Substring(lj 1).ToUpper().EndsWith("E"); // true 

ЗдесБ 'A реализуго свои намерешш, обБединнн несколБКО операции 1 . Зтот код 
легко читаетсн и редактируетсн, так как его назначение очевидно. Mbi берем строку, 
вБвделием ее частБ, приводим символбг зтои части к верхнему регистру и смотрим, 
заканчиваетси ли вввделеннБш фрагмент символом " Е". При зтом делаетсн до- 
пугцение, что все упомннутвге операции успешно завершаготсн. Хотн, разумеетсл, 
от ошибок никто не застрахован. Соответственно, с ними нужно что-то делатв. 
Сугцествует множество обЂектно-ориентированнвгх средств — конструкторБц ин- 
струментБ1 просмотра/заданин своиств, добавлешш/удалешш co6bithh, вб130вб1 
перегрузки операторов, bbi30bbi операторов преобразованин типа, — которвге не 
умегот возврагцатв код ошибки. Но даже они должнбг каким-то способом сообгцатБ 
о ее наличии. В .NET Framework и всех поддерживаемвгх зтои платформои изБгках 
программировашш д./ги зтои цели сугцествует специалвнБш механизм, назБшаемБги 
обработкоп исклтченип (exception handling). 

ВНИМАНИЕ 

НекоторБ 1 е разработчики ошибочно считакгг, что исклкзченич завислт от частотн 
возникновенич некоторого чвленич. К примеру, разработчик метода чтенил фаила 
может сказатБ: «Читал фаил, вм в итоге достигнете его конца. Так как зто случаетсл 
всегда, л заставлкз мои метод Read в зтот момент возвраидатБ специалБное значение. 
И тогда генерироватБ исклгочение не понадобитсл«. Но так считает разработчик, 
создакнции метод Read, а не тот, кто зтим методом потом полБзуетсч. 


i 


МетодБ! расширенил в C# позволлгот строитв цепочки из целого набора методов. 
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На момент созданил метода невозможно предугадатБ все ситуации, в которнх он 
будет Bbi3biBaTbc^. Соответственно, нелизл предсказати, насколико nacTbiMH станут 
nonbiTKn прочитат^ фаил до конца. Более того, так как болишинство фаилов содержит 
структурированнв!е даннне, врлд ли чтение последних фрагментов будет частмм 
собмтием. 


Механика обработки исклкзчении 

В зтом разделе рассмотренм конструкции нзмка С#, предназначеннме длл обработки 
исклгочении, хотл мм и не будем особо вдаватБСл детали. Вам важно понитб, когда 
и каким образом применнетсл обработка исклгочении. Подробнуго же информациго 
по даннои теме вбг наидете в документации на .NET Framework и спецификации 
лзБ 1 ка С#. Следует также упоминутћ, что в основе обработки исклгочении в .NET 
Framework лежит структурнал обработка исклтченип (Structured Exception 
Eiandling, SEEi) Windows. SEEi рассматриваетсн во многих источниках, в том числе 
в моеи книге «Windows via С/С++» (Microsoft Press, 2007). 

Рассмотрим код, демонстриругогции стандартное применение механизма об- 
работки исклгочении. Он дает представление о виде и предназначении блоков 
обработки исклгочении. В комментариих дано формалБное описание блоков tny, 
catch и finally. 

private void SomeMethod() { 
try { 

// Код, требутции корректного восстановленил 
// или очистки ресурсов 

} 

catch (InvalidOperationException) { 

// Код восстановленил работоспособности 
// после исклтченин InvalidOperationException 

} 

catch (IOException) { 

// Код восстановленид работоспособности 
// после исклтченид IOException 

} 

catch { 

// Код восстановленил работоспособности после осталБнмх исклтчении. 

// После перехвата исклтчении их обћ 1 чно генерирутт повторно 

// Зта тема будет рассмотрена позже 

throw; 

} 

finally { 

// Здеси находитсд код, вмполнлтции очистку ресурсов 
// после операции, начатмх в блоке try. Зтот код 
// вмполнлетсл ВСЕГДА вне зависимости от наличил исклтченив 
} 
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// КоДј следуклции за блоком finallyj внполнлетсл, если в блоке try 
// не генерировалосн исклмчение или если исклгачение бнло перехвачено 
// блоком catchj а новое не генерировалоси 

} 

Mbi рассмотрели один из возможнмх способов обработки исклгочении при 
помош,и блоков. Обмчно все вмглидит намного прогце. В болБшинстве случаев 
можно обоитисћ всего двуми блоками, например блоком try с соответствугогцим 
ему блоком finally или же napoii tny и catch. Такои сложнми пример н вмбрал 
длл демонстрации возможнмх комбинации. 

Блок try 

В блок try помегцаетси код, требугогции очистки ресурсов и/или восстановле- 
нин после исклгоченин. Код очистки содержитси в блоке f inally. В блоке try 
может располагатБСн также код, приводшции к генерации исклгоченин. Код же 
восстановленгш вставлнгот в один или псско. њко блоков catch. Один блок catch 
соответствует одному собмтиго, после которого по вашим предположенинм может 
потребоватБСн восстановление приложении. Блок try должен 6мтб свнзан хотл бм 
с одним блоком catch или f inally; сам по себе он не имеет сммсла, и C# запрегцает 
такие определенгш. 


ВНИМАНИЕ 

Иногда разработчики спрашивакзт, какои обвем кода следует размешати внутри 
блока try. Ответ на зтот вопрос зависит от управленил состолнием. Если внутри 
блока try Bbi собираетеси BbinoaHaTb набор операции, каждал из котори1х может 
статв причинои исклкзченил одного и того же типа, но при зтом способм обра- 
ботки каждого исклкзченил разнме, имеет смисл создати длл каждои операции 
собственни 1 и блок try. 


Блок catch 

В блок catch помегцагот код, которми должен вмполннтмш в ответ на исклгочение. 
Блок try может 6мтб свизан как с набором блоков catch, так и не ассоциироватћсн 
ни с одним таким блоком. Если код в блоке try не порождает исклгочение, CLR 
никогда не переходит к вмполнениго кода в соответствугогцем блоке catch. Поток 
просто пропускает их, сразу переходи к коду блока finally (если таковои, конеч- 
но, сугцествует). Вмполнив код блока finally, поток переходит к инструкции, 
следугогцеи за зтим блоком. 

Вмражение в скобках после клгочевого слова catch назмваетсн типом исклтче- 
нил (catch type). В C# зту ролд играет тип System. Exception и его производнме. 
В предмдугцем примере первме два блока catch обрабатмвали исклгоченгш типа 
InvalidOperationException (илиихпроизводнме) и IOException (или, опнтб же, 
их производнме). В последнем блоке (длн которого не бмл нвно указан тип исклго- 
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чентш) обрабатћшалисБ все осталБНБге видб1 исклточении. Зто зквивалентно блоку 
catch длн исклточении типа System. Exception, не считал того, что информацин 
исклточенил в коде, заклточенном в фигурнБге скобки, недоступна. 

ПРИМЕЧАНИЕ 

При отладке блока catch в Microsoft Visual Studio длл просмотра текутдего исклкз- 
ченил следует добавитБ в окно контролБНБ1х значении специалБнукз переменнук) 
$exception. 


Поиск подходлгцего блока catch в CLR осугцествллетсл сверху вниз, позтому 
наиболее конкретнвте обработчики должнб 1 находитБСи в начале списка. Снача- 
ла следутот потомки с наиболвшеи глубинои наследовании, потом — их базовБШ 
классБ 1 (если таковБге иметотси) и, наконец, — класс System. Exception (или блок 
с неуказаннБш типом исклгочении). В противном случае компилнтор сообгцит об 
ошибке, так как более узкоспециализированнБге блоки в такои ситуации окажутси 
дли него недостижимБши. 

Исклгочение, сгенерированное при ввшолнении кода блока try (или лгобого вбг- 
званного ;)тим блоком метода), инициирует поиск блоков catch соответствугогцего 
типа. При отсутствии совпадении CLR продолжает просматриватв стек вбгзовов 
в поисках типа исклгоченгш, соответствугогцего данному исклгочениго. Если при до- 
стижении вершинвг стека блок catch нужного типа обнаружен не будет, исклгочение 
считаетсл необработаннБш. Зту ситуациго мбг рассмотрим чутБ позже. 

При обнаруженгш блока catch нужного типа CLR исполниет все внутренние 
блоки finally, начинан со свизанного с блоком tny, в котором 6 бшо вброшено 
исклгочение, и заканчиваи блоком catch нужного типа. При зтом ни один блок 
f inally не вБшолниетсн до завершенгш деиствии с блоком catch, обрабатвшагогцим 
исклгочение. 

После того как код внутренних блоков f inally будет ввшолнен, исполннетси 
код из обрабатБгвагогцего блока catch. Здеск вБгбираетсн способ восстановленгш 
после исклгоченгш. Затем можно ввгбратв один из трех вариантов деиствии: 

□ егце раз сгенерироватв то же исклгочение дли передачи информации о нем коду, 
расположенному вБшге в стеке; 

□ сгенерироватБ исклгочение другого типа длл передачи дополнителБнои инфор- 
мации коду, расположенному вБшге в стеке; 

□ позволитб программному потоку вБгити из блока catch естественнБш образом. 

О том, в каких ситуацгшх следует ввгбратв каждБш из зтих способов, мбг по- 
говорим немного позже. При ввгборе первого или второго варианта деиствии CLR 
работает по уже рассмотреннои схеме: просматривает стек вбгзовов в поисках блока 
catch, тип которого соответствует типу сгенерированного исклгоченгш. 
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В последнем же случае происходит переход к блоку f inally (если он, конечно, 
сушествует). После вмполненин всего содержагцегосн в нем кода управление пере- 
ходит к расположеннои после блока f inally инструкции. Если блок f inally отсут- 
ствует, поток переходит к инструкции, расположеннои за последним блоком catch. 

В C# после типа перехватмваемого исклгоченип можно указатБ ими перемен- 
нои, которан будет ссмлатћсн на сгенерированнми обвект, потомок класса Sy stem . 
Exception. В коде блока catch зту переменнуго можно исполБЗОватБ длн полученин 
информации об исклгочении (например, даннмх трассировки стека, приведшеи 
к исклгочениго). Обвект, на которми ссмлаетси переменнаи, в принципе можно 
редактироватБ, но и рекомендуго рассматриватБ его как предназначеннми толбко 
длл чтенгш. Впрочем, подробнми разговор о типе Exception и манипулнциих им 
вмнесен в отделћнми раздел. 

ПРИМЕЧАНИЕ 

Можно создати собитие FirstChanceException класса AppDomain и получати инфор- 
мацик) об исклкзченилх егце до того, как CLR начнет искати их обработчики. Подробно 
зта тема рассматриваетсл в главе 22. 


БлокЛпаМу 

Код блока finally вмполниетси всегда 1 . Обмчно зтот код производит очистку по- 
сле вмполнешш блока try. Если в блоке tny бмл открмт некии фаил, блок f inally 
должен содержатБ закрБшагогции зтот фаил код: 

private void ReadData(String pathname) { 

FileStream fs = null; 
try { 

fs = new FileStream(pathname, FileMode.Open); 

// Обработка даннмх в фаиле 

} 

catch (IOException) { 

// Код восстановленил после исклтченил IOException 

} 

finally { 

// Фаил облзателнно следует закрнтБ 
if (fs != null) fs.Close(); 

} 

} 


1 Прермвание потока или вшгрузка домена приложении лвллетсл источником исклгоченил 
ThreadAbortException, обеспечивагогцего вшполнение блока finally. Если же поток прерш- 
ваетсл функциеи TerminateThread или методом FailFast класса System.Environment, блок 
finally не вшполнлетсл. Разумеетсл, Windows производит очистку всех ресурсов, которћге 
исполвзовалисв прерваннБ1м процессом. 
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Если код блока try вмполннетсл без исклгочении, фаил закрмваетсл. Впрочем, 
посколБку даже исклгочение не помешает вмполнениго кода в блоке f inally, фаил 
гарантированно будет закрмт. А если поместитБ инструкциго закрмтин фаила после 
блока f inally, в случае неперехваченного исклгоченин фаил останетсн открмтмм 
(до следугошего прохода уборшика мусора). 

Блок try может сугцествоватБ и без блока finally, ведБ иногда его код просто 
не требует последугогцеи очистки. Однако если Bbi решили создатБ блок f inally, 
его следует поместитк после всех блоков catch. И помните, что одному try может 
соответствоватв толбко один блок f inally. 

Достнгнув конца блока f inally, поток переходит к инструкции, расположеннои 
после зтого блока. Запомните, что в блок f inally помегцаетсл код дли вБшолненгш 
завершагогцеи очитски. И он должен вбгполннтб толбко те деиствгш, которвге не- 
обходимвг дли отменБг операции, начатнгх в блоке try. Код блоков catch и f inally 
следует делатв по возможности коротким (ограничивансБ однои или двумл стро- 
ками) и по возможности работагогцим без исклгочении. Однако иногда случаетси 
так, что источником исклгоченгш становитсн код восстановленгш или код очистки. 
Обвшно зто указБгвает на наличие сернезнБгх ошибок. 

Всегда сугцествует вероитноств того, что во времн ввшоленнгш кода восстанов- 
ленгш или очистки произоидет сбои, и будет ввгдано исклгочение. Впрочем, такаи 
ситуацгш маловеронтна, а ее возникновение свидетелБСтвует о возникновении оченв 
серБезнБгх проблем в программе (скорее всего, о повреждении текугцего состоннгш). 
Если источником исклгоченгш становнтсл блоки catch или finally, CLR продол- 
жает работу как в случае, когда исклгочение генерируетсн после блока finally. 
Просто при зтом терлетси информацгш о первом исклгочении, вброшенном в блоке 
try. Скорее всего (и даже желателвно), зто новое исклгочение останетсн необрабо- 
таннБгм. После зтого CLR завершает процесс, уничтожан поврежденное состонние. 
Продолжение работвг приложенгш в подобном случае привело 6бг к непредсказуе- 
мбгм резулБтатам и, вероитно, к понвлениго дефектов в системе безопасности. 

С моеи точки зренгш, длл механизма обработки исклгочении следовало 6бг вбг- 
братБ другие клгочевБге слова. Ведв программисту нужно всего лишб вбшолнитб 
фрагмент кода. А если что-то поидет не так, либо восстановитБ приложение после 
ошибки и двигатБСи далБше, либо вернутБСн в состонние до возникновенгш про- 
блем и сообгцитБ о неполадках. Программистам также нужно гарантированное 
вБгполнение завершагогцеи очистки. Слева показан код, правилБНБш с точки зренгш 
компилнтора, а справа — синтаксис, которвш предпочел 6 бг видетБ н: 


void Method() { 

void Method() { 

try { 

try { 

} 

} 
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catch (XxxException) { 

handle (XxxException) { 

} 

} 

catch (YyyException) { 

handle (YyyException) { 

} 

} 

catch { 

compensate { 

...; throw; 

...; throw; 

} 

} 

finally { 

cleanup { 

} 

} 

} 

} 


CLS-coBMecTHMbie и CLS-HecoBMecTHMbie иоаноченив 

Все измки программированин, ориентированнме на CLR, должнм поддерживатБ 
создание обвектов класса Exception, так как зтого требует обгцензБЖОван специфи- 
кацин (Сошшоп Language Specification, CLS). Но на самом деле, CLR разрешает 
создаватБ зкземплнрБг лгобого типа, в резулвтате в некоторвгх нзвгках iiohb.tmiotcm 
несовместимБге с CLS исклточешга типа Stning, Int32 или DateTime. Компилнтор 
C# разрешает генерироватБ толбко обвектБ 1 , производнБ 1 е от класса Exception, в то 
времн как в других нзБтжах зто ограничение отсутствует. 

Многие программистБ 1 не знатот, что длн передачи исклточенин можно генериро- 
ватБ обвект лтобого типа, позтому они полБзутотсн толбко обвектами, производнБши 
от класса Exception. До вкгхода версии CLR 2.0 в блоках catch перехватвшалисБ 
толбко CLS-coBMecTHMKie исклгочешга. Если метод на C# ввшвшал метод, написан- 
нб 1 и на другом нзБже, и тот генерировал CLS -несовместимое исклгочение, его 6бшо 
невозможно перехватитв, что чревато нарушением загцитБ1. 

Начинаи с версии 2.0, в CLR поивилсл класс RuntimeWrappedException, опре- 
деленнБ 1 и в пространстве имен System . Runtime . CompilerServices. Лвлиисб 
производнБш от класса Exception, он представллет собои CLS -совместимвш тип 
исклгочении. Зтот класс обладает закрБ1ТБ1м полем типа Object, к которому можно 
обратитБСи через предназначенное толбко длн чтешга своиство WrappedException 
того же класса. В CLR 2.0 при генерации CLS -несовместимого исклгоченгга авто- 
матически создаетси зкземплнр класса RuntimeWrappedException, закрвшому полго 
которого присваиваетсл ссвшка на вброшеннБш обвект. Таким способом несовме- 
стимБге с CLS исклгоченгга преврагцаготсл в CLS-coBMecTHMBie. В итоге лгобои код, 
умегогции перехватвшатБ исклгоченгга типа Exception, будет перехватБшатБ и все 
осталБшле исклгоченгга, что устраниет угрозу безопасности. 

До версии 2.0 перехват CLS-HecoBMecTHMBix исклгочении осугцествлнлсн с по- 
могцбго примерно такого кода: 
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private void SomeMethod() { 
try { 

// ВнутрБ блока try поме!дак)т код, требукпции корректного 
// восстановленил работоспособности или очистки ресурсов 

} 

catch (Exception е) { 

// До C# 2.0 зтот блок перехватмвал толико СЕБ-совместимне исклгаченив 
// В C# 2.0 зтот блок научилсв перехватнвати также 
// СЕ5-несовместимуе исклгаченил 

throw; // Повторнал генерацил перехваченного исклкзченил 

} 

catch { 

// Во всех версилх C# зтот блок перехвативает 
// и совместимнвЈ и несовместимме с CLS исклмченил 
throw; // Повторнал генерацил перехваченного исклкзченил 

} 

} 

Узнав, что CLR подцерживает теперг> оба вида исклгочении, некоторме разработ- 
чики стали писатБ два блока catch (как показано в предБвдутцем фрагменте кода), 
что 6 б 1 перехватБшатБ исклгоченин обоих видов. Если зтот код перекомпилироватв 
дли CLR 2.0, второи блок catch никогда не будет вбшолнитбсн, а компилитор bhi- 
даст предупреждение (CS1058: предБ1дугции блок catch уже перехватБшает все 
исклгоченгш. ОсталБшде обвектБ1 заклгочаготсн в обертку класса System . Runtime . 
CompilerServices.RuntimeWrappedException): 

CS1058: A previous catch clause already catches all exceptions. All non-exceptions 
thrown will be wrapped in a System.Runtime.CompilerServices.RuntimeWrappedException 

Естб два пути переноса кода более ранних версии в .NET Framework 2.0. Во- 
первБ1х, можно обБединитБ два блока catch. Именно так рекомендуетсл деиство- 
ватв. Однако можно также сообгцитк CLR, что код вашеи сборки будет работатв 
по «старБ1м» правилам, то еств что блоки catch (Exception) не должнбг пере- 
хватБшатБ зкземплирБг нового класса RuntimeWrappedException. Вместо зтого, 
среда CLR должна извлечв из обертки СI .S -песо i: местим i>i ii обвект и вБгзвгватБ 
ваш код толбко при наличии в нем блока catch, в котором не определено ника- 
кого типа. Чтобвг сообгцитБ CLR об зтом, к сборке нужно применитБ зкземплнр 
RuntimeCompatibilityAttribute, например, так: 

using System.Runtime.CompilerServices; 

[assembly:RuntimeCompatibility(WrapNonExceptionThrows = false)] 


ПРИМЕЧАНИЕ 

Зтот атрибут деиствует науровне целои сборки. В однои сборке нелцзл совмеидатБ 
исклкзченил в обертке и без нее. Нужно соблкздатБ особукз осторожностБ при добав- 
лении в сборку нового кода (которми ожидает от CLR исклкзчении в обертке класса 
System.Runtime.CompilerServices.RuntimeWrappedException), где естц старни код 
(в котором CLR не помешдет исклкзченил в обертку). 
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Класс System.Exception 

CLR позволнет генерироватБ в качестве исклгочении зкземплнрБ 1 лгобого типа — от 
Int 32 до Stning. Но в Microsoft решили, что не стоит заставлитБ все чзбжи гене- 
рироватБ и перехватБшатБ исклгоченин произволБного типа. Соответственно, 6 бш 
создан тип System . Exception. Именно исклгочешш зтого типа и его производшлх 
должнб1 перехватБшатБСл во всех CLS-cobm6Cthmbix лзв 1 ках программировашш. 
CLS-coBMecTHMBiMn назвшаготсл типб 1 исклгочении, производнБШ от типа System . 
Exception. КомпилнторБ 1 C# и многих других нзбшов позволнгот коду генерироватв 
толбко CLS-coBMecTHMKie исклгоченгш. 

System. Exception — оченв простои тип с набором своиств, перечисленнвш 
в табл. 20.1. Скорее всего, обрагцатвсн к зтим своиствам в своем коде вам никогда 
не придетсл. Их шцут в отчете отладчика или в авариином дампе памнти после 
прекрагцешш работв! приложенгш из-за необработанного исклгочешш. 


Таблица 20.1. OTKpbiTbie своиства типа System.Exception 


Своиство 

Доступ 

Тип 

Описание 

Message 

Толбко длл 

чтенил 

String 

Текст c описанием причинБ! исклго- 
ченил. Если исклгочение не удаетсл 
обработатБ, сообгцение записБтаетсл 
в журнал. КонечнБш полБзователлм зто 
сообгцение недоступно, позтому его мак- 
сималвно насБнцагот техническими под- 
робностлми, которБге могут оказатБсл 
полезнБши длл разработчиков 

Data 

Толбко длл 

чтенил 

IDictionary 

Ссвшка на набор пар «параметр- 
значение». 06 б1чно, перед тем как сге- 
нерироватБ исклгочение, код добавллет 
записв в зтот набор. Перехватвшагогции 
исклгоченил код запрашивает зти записи 
и исполвзует полученнуго информациго 
длл своеи работБ 1 

Source 

Чтение/за- 

ПИСБ 

String 

Имл сборки, сгенерировавшеи исклш- 
чение 

StackTrace 

Толбко длл 

чтенил 

String 

Имена и сигнатурБ1 методов, вбгзов кото- 
рв1х стал источником исклгоченил. Чрез- 
вБ 1 чаино полезное длл отладки своиство 

TargetSite 

Толбко длл 

чтенил 

MethodBase 

Имл метода, ставшего источником 

исклшченил 


продолжение # 
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Таблица 20.1 (продолжение) 


Своиство 

Доступ 

Тип 

Описание 

HelpLink 

Толбко длл 

чтенил 

String 

Адрес документации с информациеи 
об исклточении (например, file://C:\ 
MyApp\Help.htm#MyExceptionHelp). 

С точки зренгш безопасности полвзовате- 
ли не должнм видетв сведении о необра- 
ботанннх исклгоченгшх, позтому данное 
своиство на практике исполвзуетсл редко 

InnerException 

Толбко длл 

чтенил 

Exception 

Если текушее исклгочение 6 бшо вброше- 
но в ходе обработки предмдушего, ука- 
знвает на зто предвгдугцее исклгочение. 
Обмчно данное поле содержит значение 
null. Тип Exception содержит также от- 
крв 1 тми метод GetBaseException, про- 
сматривакиции свлзаннни список вну- 
тренних исклгочении и возврагцагогции 
самое первое из них 

HResult 

Чтение/за- 

ПИСБ 

Int32 

32-разридное значение, исполБзуемое при 
интеграции управлнемого кода с машин- 
нмм. Е1апример, когда функции СОМ 

API возврагцагот кодм ошибок EIRESULT, 
CLR генерирует обвект исклгоченгш, про- 
ИЗВОДНБ1И от Exception, и сохраннет значе- 
ние EIRESULT в зтом своистве 


ХотелосЂ бм подробнее поговоритБ о доступном толбко длн чтении своистве 
StackTrace класса System.Exception. Блок catch может прочитатћ его длн полу- 
ченгш информации о том, какои именно метод стал источником исклгочешш. Зта 
информацгш может 6бгтб весБма ценнои длл поиска обвекта, ставшего источником 
исклгочешш, и последугогцего исправленгш кода. При обрагцении к зтому своиству 
вб 1 фактически обрагцаетесБ к коду в CLR, посколвку своиство не просто возврагцает 
строку. При создании обвекта типа, производного от Exception, своиству StackTrace 
присваиваетси значение null. И соответственно, при попвгтке прочитатк своиство 
вб 1 получили 6бг не резулнтат трассировки стека, а null. 

При понвлении исклгоченгш CLR делает записв с указанием места его возник- 
новенгш. Когдаблок catch получает исклгочение, CLR записвшает, где именно оно 
6бшо обнаружено. Если внутри блока catch обратитвсл к своиству StackTrace 
обвекта, сгенерированного при поивлении исклгоченгш, реализугогции зто свои- 
ство код обратитсл к CLR, где и будет создана строка, содержагцал имена всех 
методов от точки, в которои 6бшо вброшено исклгочение, до точки, где оно 6бшо 
перехвачено. 
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ВНИМАНИЕ 

При полвлении исклкзченил CLR обнуллет его началннукз точку. То ести CLR запо- 
минает толико место полвленил самого последнего исклгоченил. 

Следуклции код генерирует то же исклкзчение, которое бмло перехвачено, и за- 
ставлиет CLR обнулитБ пача. њпуто точку: 

private void SomeMethod() { 
try { ... } 
catch (Exception e) { 

throw e; // CLR считает, что исклк>чение возникло тут 
// FxCop сообшает об ошибке 

} 

} 

В противоположностБ зтому, при повторном вБгзове перехваченного исклкзченин 
с помогцбк) клкзчевого слова throw удаленин из стека информации о началвнои 
точке не происходит. Пример: 

private void SomeMethod() { 
try { ... } 
catch (Exception e) { 

throw; // CLR не менлет информацик) o началцнои точке исклк)ченил. 

// FxCop НЕ сообшает об ошибке 

} 

} 

Зти два фрагмента кода отличакзтси толбко тем, где, по мненшо CLR, 6б1ло 
сгенерировано иск. почспие. К сожаленшо, при первом или повторном вБ 130 ве ис- 
клкзчешш Windows обнулиет стек с информациеи о началвнои точке. И в случае 
необработанного иск./почепии в систему сбора информации об ошибках Windows 
уходлт сведенин о последнем вброшенном исклгочении, даже если CLR «знает», 
где именно 6бшо сгенерировано самое первое исклгочение. Зто сервезно усложннет 
отладку приложении. Некоторвш разработчикам подобнан ситуацин кажетсн недо- 
пустимои, позтому они ввгбирагот другои способ реализации кода, гарантиругогции 
истинностб информации о первоначалБнои точке возникновенин исклгоченгш: 

private void SomeMethod() { 

Boolean trySucceeds = false; 
try { 

trySucceeds = true; 

} 

finally { 

if (!trySucceeds) { /* код перехвата исклвченил */ } 

} 


} 
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Строка, возвратцаеман своиством StackTrace, не вклгочает в себч имен методов, 
расположеннмх в стеке вмзова вмше точки приннтии исклгочении блоком catch. 
Дли отслеживанин всего стека с самого начала до момента обработки исклгочентш 
исполкзуите тип System . Diagnostics . StackTrace. Он определнет своиства и ме- 
тодб1 , дагогцуго разработчикам возможностб программно управлнтБ трассировкои 
стека и составлнгогцими его кадрами. 

Сугцествует несколвко конструкторов, позволнгогцих получитв обвект StackT race. 
Некоторкге из них строит кадрнг от начала потока до момента понвленгш обвекта 
StackTrace. Другие — инициализиругот кадрвг обвекта StackT race, передаваи ему 
в качестве аргумента обвект, производнБпг от типа Exception. 

Если CLR обнаруживает дли ваших сборок символические имена отладки 
(находнгциесн в фаилах с расширением pdb), строка, возврагцаеман своиством 
StackTrace обвекта System. Exception или методом ToString обвекта System. 
Diagnostics . StackTrace, содержит пути фаилов исходного кода и номера строк. 
Зта информацин чрезввгчаино полезна длл отладки. 

В резулБтатах трассировки стека можно обнаружитв, что имена некоторнгх из 
ББгзБшавшихси методов отсутствугот. Такан ситуацгш может возникнутв по двум 
причинам. Во-перввгх, в стеке содержитсн информацгш о том, куда должен вернутв 
управление поток, а не откуда произошло обрагцение. Во-вторвтх, ЈГГ-компшштор 
может вбшолннтб подстановку (inline) кода методов в ввгзБшагогции код, что6бг из- 
бежатБ слишком болкшого числа вбгзовов, и возврагцатв резулБтат вБгзова толбко 
одного метода. Многие компилиторБг (в том числе С#) предлагагот переклгочателв 
команднои строки /debug. При его исполБЗОвании компиллтор вклгочает в ре- 
зулБтиругогцуго сборку информациго, заставлнгогцуго JIT -компилнтор прекратитв 
подстановку методов. В резулвтате трассировка стека становитсл более полнои 
и содержателвнои в процессе отладки. 

ПРИМЕЧАНИЕ 

JIT -компилптор проверлет назначеннБ 1 и сборке атрибут System.Diagnostics. 
DebuggableAttribute. Компиллтор C# назначает зтот атрибут автоматически. Уста- 
новка флага DisableOptimizations заставллет JIT -компиллтор прекратитБ подстановку 
методов сборки. В C# флаг устанавливаетсл переклкзчателем команднои строки 
/debug. Применив к методу настраиваемБ 1 и атрибут System.Runtime.CompilerServices. 
MethodlmplAttribute, bw можете запретитБподстановку какдлл отладочнои, таки длл 
рабочеи конфигурации. Вот пример определенил метода, запреш,а 1 оидего подста- 
новку: 

using System; 

using System.Runtime.CompilerServices; 
internal sealed class SomeType { 

[MethodImpl(MethodImplOptions.Nolnlining)] 
public void SomeMethod() { 

} 

} 
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Классн исклк>чении, определеннне в FCL 

В библиотеке классов Framework Class Library определено множество типов ис- 
клгочении (нвлнгондихсн потомками класса System . Exception). Типм, определеннме 
в сборке MSCorLib.dll, иллгострирует показаннан далее иерархил; другие сборки 
содержат егце болБше типов исклгочении (зта иерархии получена при помогци при- 
ложенип, демонстриругогцегосн в главе 23). 

System.Exception 

System.AggnegateException 
System.ApplicationException 

System.Reflection.InvalidFilterCriteriaException 
System.Reflection.TargetException 
System.Reflection.TargetInvocationException 
System.Reflection.TargetParameterCountException 
System.Threading.WaitHandleCannotBeOpenedException 
System.Diagnostics.Tracing.EventSourceException 
System.InvalidTimeZoneException 

System.10.IsolatedStorage.IsolatedStorageException 
System.Runtime.CompilerServices.RuntimeWrappedException 
System.SystemException 

System.Threading.AbandonedMutexException 
System.AccessViolationException 
System.Reflection.AmbiguousMatchException 
System.AppDomainUnloadedException 
System.ArgumentException 

System.ArgumentNullException 
System.ArgumentOutOfRangeException 
System.Globalization.CultureNotFoundException 
System.Text.DecoderFallbackException 
System.DuplicateWaitObjectException 
System.Text.EncoderFallbackException 
System.ArithmeticException 

System.DivideByZeroException 
System.NotFiniteNumberException 
System.OverflowException 
System.ArrayTypeMismatchException 
System.BadImageFormatException 
System.CannotUnloadAppDomainException 
System.ContextMarshalException 

System.Security.Cryptography.CryptographicException 

System.Security.Cryptography.CryptographicUnexpectedOperationException 
System.DataMisalignedException 
System.ExecutionEngineException 
System.Runtime.InteropServices.ExternalException 
System.Runtime.InteropServices.COMException 
System.Runtime.InteropServices.SEHException 
System.FormatException 

System.Reflection.CustomAttributeFormatException 
System.Security.HostProtectionException 


продолжение # 
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System.Security . Principal . IdentityNotMappedException 
System.IndexOutOfRangeException 
System.InsufficientExecutionStackException 
System.InvalidCastException 

System.Runtime.InteropServices.InvalidComObjectException 
System.Runtime.InteropSenvices.Invalid01eVariantTypeException 
System.InvalidOpenationException 
System.ObjectDisposedException 
System.InvalidPrognamException 
System.10.IOException 

System.IO.DirectoryNotFoundException 
System.10.DriveNotFoundException 
System.10.EndOfStreamException 
System.I0.FileLoadException 
System.I0.FileNotFoundException 
System.10.PathTooLongException 
System.Collections.Generic.KeyNotFoundException 
System.Runtime.InteropServices.MarshalDirectiveException 
System.MemberAccessException 
System.FieldAccessException 
System.MethodAccessException 
System.MissingMemberException 
System.MissingFieldException 
System.MissingMethodException 
System.Resources.MissingManifestResourceException 
System.Resources.MissingSatelliteAssemblyException 
System.MulticastNotSupportedException 
System.NotImplementedException 
System.NotSupportedException 

System.PlatformNotSupportedException 
System.NullReferenceException 
System.OperationCanceledException 

System.Threading.Tasks.TaskCanceledException 
System.OutOfMemoryException 

System.InsufficientMemoryException 
System.Security.Policy.PolicyException 
System.RankException 

System.Reflection.ReflectionTypeLoadException 
System.Runtime.Remoting.RemotingException 

System.Runtime.Remoting.RemotingTimeoutException 
System.Runtime.InteropServices.SafeArrayRankMismatchException 
System.Runtime.InteropServices.SafeArrayTypeMismatchException 
System.Security.SecurityException 
System.Threading.SemaphoreFullException 
System.Runtime.Serialization.SerializationException 
System.Runtime.Remoting.ServerException 
System.StackOverflowException 
System.Threading.SynchronizationLockException 
System.Threading.ThreadAbortException 
System.Threading.ThreadInterruptedException 
System.Threading.ThreadStartException 
System.Threading.ThreadStateException 
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System. Т imeoutException 

System.TypeInitializationException 

System.TypeLoadException 

System.DllNotFoundException 
System.EntryPointNotFoundException 
System.TypeAccessException 
System.TypeUnloadedException 
System.UnauthorizedAccessException 

System.Security.AccessControl.PrivilegeNotHeldException 
System.Security.VerificationException 
System.Security.XmlSyntaxException 
System.Threading.Tasks.TaskSchedulerException 
System.TimeZoneNotFoundException 

Специалистм Microsoft хотели сделатБ тип System. Exception базовмм длл 
всехисклгочении, адвадругихтипа, System.SystemException и System.Applica- 
tionException, стали бм его непосредственнмми потомками. Кроме того, исклго- 
ченил, вброшеннме CLR, стали бм производнмми от типа SystemException, в то 
времн как исклгоченгш, понвившиесл в приложенинх, должнм бмли наследоватБ 
от ApplicationException. Зто дало бм возможностб написатБ блок catch, пере- 
хватБшагогции как все CLR -исклгоченгш, так и все исклгоченгш приложении. 

Однако на практике зто правило соблгодаетсл не полностбго; некоторБге ис- 
клгоченил нвлнготсл примБгми потомками типа Exception (IsolatedStorage- 
Exception), некоторБге CLR -исклгоченгш наследугот от типа ApplicationException 
(TargetInvocationException), а некоторБге исклгоченгш приложении — от типа 
SystemException (FormatException). Из-за зтои путаницБг типбг SystemException 
и ApplicationException ненесут никакои особои смбгсловои нагрузки. В настоигцее 
времн в Microsoft подумвшагот вообгце убратв их из иерархии классов исклгочении, 
но зто невозможно, так как приведет к нарушениго работвг уже имегогцихси при- 
ложении, в которвгх исполБзуготсн зти классБг. 


Генерирование исклк>чении 

При реализации своего метода следует сгенерироватБ исклгочение, если метод не 
в состоинии решитв возложеннуго на него задачу. При зтом необходимо учитвшатв 
два фактора. 

Во-перввгх, следует понитб, к какому производному от типа Exception типу 
будет относитбси ваше исклгочение. ВвгбиратБ следует осмотрителБно. Подумаите 
о том, каким образом код, расположеннБпг вБшге по стеку вбгзовов, сможет получатв 
информациго о неудачнои работе метода, что6бг вбшолнитб восстаиовителБНБге 
операции. Можно восполБЗОватБСн длн зтои цели одним из типов, определеннвгх 
в FCL, но может оказатвси и так, что там пока отсутствует подходлгции тип. В та- 
ком случае вам потребуетси определитв собственнБпг тип, производнБш от класса 
System.Exception. 
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Если вм собираетесћ создатБ иерархиго исклгочении, постараитесБ, что 6 б 1 она 
содержала как можно менБше базовБ1х классов. Дело в том, что базовБге классБ1 
зачастуго обрабатБшагот несколБКО ошибок по одним правилам, а зто может 6 б 1 тб 
опасно. Соответственно, никогда не следует создаватБ о 6 ђсктб 1 System . Exception 
и всегда нужно соблгодатБ максималБнуго осторожностБ при генерировании ис- 
клгочении базовБ 1 х классов 1 . 

ВНИМАНИЕ 

В данном случае приходитсл также иметБ дело с ограниченилми, свпзаннБ 1 ми 
с поддержкои версии. Если определитБ новбш тип исклкзченил как производнми от 
суидествукзидего, код, перехватБ 1 вавшии исклкзченил старого типа, будет работатБ и 
с новб1м типом. В некотормхсценарилхтакое поведение требуетсп, в других— нет. 
Becb вопрос в том, каким образом код, перехватмвакшдии исклкзченил базового 
класса, реагируетнатип исклкзченил и производнмеот неготипм. Не ожидавшии по- 
лвленил HOBbix типов код можетповести себл непредсказуемо и даже стати причинои 
бреши в системе безопасности. Определл 101 ции новми тип исклкзченил программист 
не может знати всех мест, в котормх окажетсл перехваченное базовое исклкзчение. 
Не осведомлен он и о способахего обработки. Позтому принптиоднозначно верное 
решение в подобнои ситуации, увм, невозможно. 


Во-вторБ1х, следует решитБ, какое строковое сообгцение должно 6 б 1 тб передано 
конструктору исклгоченил. Генерирование исклгочении должно сопровождатБСи 
подробнои информациеи о том, почему метод не смог решитБ свого задачу. При об- 
работке перехваченного исклгоченин зто сообгцение остаетси невидимБш. С другои 
сторонБц если исклгочение останетсп необработаннБш, оно с 6олбшои вероптностБго 
будет зарегистрировано в журнале. Необработанное исклгочение свидетелБСтвует 
о наличии в приложении дефекта, об искоренении которого должен позаботитБСи 
разработчик. Копсчппс полБЗОвателинеимегот доступакисходному коду инемогут 
перекомпилироватБ программу. Соответственно, не видлт они и данного сообгце- 
нгга, позтому туда можно вклгочатБ всго техническуго информациго, необходимуго 
дли устраненгга дефекта. 

Более того, так как все разработчики должнбг пониматБ англиискии нзбгк 
(ведБ ПЗБ1КИ программировангга, а также FCL-Knaccbi и FCL -методБ! написанБ1 на 
англииском), не имеет смБ 1 Сла локализовБ1ватБ текст сообгценип. Впрочем, если 
Bbi создаете библиотеку классов длл разработчиков, говорнгцих на других нзБгках, 
ничто не запрегцает вбшолнитб локализациго. Именно по зтои причине Microsoft 
локализует сообгценгга исклгочении, генерируемБгх FCL. 


1 Класс System.Exception следовало бш о6ђлвитб абстрактнБШ, что6бг код, которБи! ПБгта- 
етсл сгенерироватБ его, даже не компилировалсл. 
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Создание классов исклкзчении 

К сожаленшо, процедура созданин классов исклгочении трудоемка и часто сопро- 
вождаетсл ошибками. Дело в том, что все типм, производнме от типа Exception, 
должнм иметБ возможностб сериализоватБСн, а зто означает, что они не могут вбшти 
за границБ1 домена приложении и их нелнзи записБшатБ в журнал или базу даннБ1х. 
Впрочем, особенности сериализации рассматриваготсн в главе 24, а пока дли про- 
ctotbi и создал обобшеннБ 1 и класс Exception<TExceptionArgs>: 

[Serializable] 

public sealed class Exception<TExceptionArgs> : Exceptionj ISerializable 
where TExceptionArgs : ExceptionArgs { 

private const String c_args = "Args"; // Длл (де)сериализации 
private readonly TExceptionArgs m_args; 

public TExceptionArgs Args { get { return m_args; } } 

public Exception(String message = null, Exception innerException = null) 

: this(null, message^ innerException) { } 

public Exception(TExceptionArgs args, String message = null^ 

Exception innerException = null): base(message, innerException) { 
m_args = args; } 

// Конструктор длн десериализации; так как класс запечатан, конструктор 
// закрит. Длн незапечатанного класса конструктор должен бмтц затишеннмм 
[SecurityPermission(SecurityAction . LinkDemand, 

Flags=SecurityPermissionFlag.SerializationFormatter) ] 
private Exception(SerializationInfo info, StreamingContext context) 

: base(info, context) { 
m_args = (TExceptionArgs)info.GetValue( 
c_args, typeof(TExceptionArgs)); 

} 

// Метод длн сериализации; он открмт из-за интерфеиса ISerializable 
[SecurityPermission(SecurityAction . LinkDemand, 

Flags=SecurityPermissionFlag.SerializationFormatter) ] 
public override void GetObjectData( 

Serializationlnfo info, StreamingContext context) { 
info.AddValue(c_args, m_args); 
base.GetObjectData(info, context); 

} 

public override String Message { 
get { 

String baseMsg = base.Message; 

return (m_args == null) ? baseMsg : baseMsg + " (" + m_args.Message + ")"; 

} 

} 

продолжепие & 
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public ovenride Boolean Equals(Object obj) { 

Exception<TExceptionAngs> othen = obj as Exception<TExceptionAngs>; 
if (obj == null) netunn false; 

netunn Object.Equals(m_angs, othen.m_angs) && base.Equals(obj); 

} 

public ovennide int GetHashCode() { netunn base.GetHashCode(); } 

} 

ОченБ прост и базоввш класс ExceptionArgs, которћш ограничиваетсл класс 
TExceptionArgs. Вот как он вб 1 гллдит: 

[Serializable] 

public abstract class ExceptionAngs { 

public virtual String Message { get { neturn String.Empty; } } 

} 


Имен зти два класса, н могу легко определнтв дополнителБНБге классБ1 исклгоче- 
нии. Скажем, тип исклточсииа, указБшакпции на нехватку свободного пространства 
на диске, может ввшлндетБ так: 

[Serializable] 

public sealed class DiskFullExceptionAngs : ExceptionArgs { 
private neadonly String m_diskpath; // закрмтое поле, задаетсл 

// во времл созданил 

public DiskFullExceptionArgs(String diskpath) { m_diskpath = diskpath; } 

// Открнтое предназначенное толбко длн чтенил своиство, 

// которое возвратдает поле 

public String DiskPath { get { retunn m_diskpath; } } 

// Переопределение своиства Message длл вклктченил в него нашего полн 
public overnide Stning Message { 
get { 

retunn (m_diskpath == null) ? base.Message : "DiskPath=" + m_diskpath; 

} 

} 

} 

И если в зтот класс не нужно вклгочатБ дополнителБНБ1е дашњ 1 С, он будет вбњ 
гллдетБ совсем просто: 

[Serializable] 

public sealed class DiskFullExceptionAngs : ExceptionArgs { } 

Теперв можно написатБ код, генериругогции и перехватБшагогции такое исклго- 
чение: 

public static void TextException() { 
try { 

throw new Exception<DiskFullExceptionArgs>( 

new DiskFullExceptionArgs(@"C:\"), "The disk is full"); 
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} 

catch (Exception<DiskFullExceptionArgs> е) { 
Console.WriteLine(e.Message); 

} 


ПРИМЕЧАНИЕ 

Хотелосв бн сделати пару замечании по поводу кпасса Exception<TExceptionArgs>. 
Во-первнх, лкзбои определеннши с его помоидик) тип исклкзченил будет производни 1 м 
от System.Exception. Зто не проблема длл болвшинствасценариев, болеетого, даже 
предпочтителино исполвзовањ широкукз иерархик)типов. Во-вторнх, в диалоговом 
окне, полвллкицемсл в Visual Studio при наличии необработанннх исклкзчении, не 
отображаетсл параметр обобиденного типа Exception<T>, как показано на следуко- 
идем рисунке. 



ПродуктивностБ вместо надежности 

А начал заниматБСн программированием в 1975 году. Написав изрндное количество 
программ на нзБгке BASIC, л заинтересовалсн аппаратнћш обеспечением и перешел 
на нзб 1 К ассемблера. Егце через некоторое времн л переклгочилсн на нзбгк С, дагогции 
доступ к аппаратному обеспечениго на более вбгсоком уровне абстракции и облег- 
чагогции программирование. Л писал код дли операционнБгх систем, длн платформ, 
длл библиотек. И всегда старалси сделатв свои код по возможности компактнвгм 
и бБгстрБгм, потому что длн хорошеи работБг приложенгш качественнБгм должно 
6 бгтб не толбко само приложение, но и исполБзуемБге им операционнан система 
и библиотеки. 

Также внимателБно л отпосилси к восстановлениго после ошибок. Ввгделнн па.мггњ 
(при помогци оператора new в С++ или методов malloc, HeapAlloc, VintualAlloc 
и т. п.), л всегда проверил возврагцаемое значение, чтобвг убедитвси, что памити 
деиствителБно хватает. При неудовлетворителвном резулнтате запроса л програм- 
мировал обходнои путв, гарантирул, что состонние осталБнои части программнг 
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останетсл незатронутмм и что вмзмвакнцан сторона получит сообтцение об ошибке 
и сможет приннтБ мерм по ее исправленшо. 

По какои-то необЂиснимои причине при написании кода .NET Framework 
многие программистн не практикугот подобнми подход. ВероитностБ столкнутБСн 
с нехваткои памнти сугцествует всегда, но и практически никогда не вижу блок 
catch с кодом восстановленин после исклгоченгш OutOfMemoryException. Более 
того, мне встречалисЂ разработчики, утверждавшие, что CLR не позволлет про- 
граммам перехватмватв зто исклгочение. Разумеетси, зто неправда. На самом деле 
при вмполнении управлиемого кода возможнм различнме ошибки, но н егце не 
сталкивалси с разработчиками, которме писали бм код длн восстановленгш после 
потенциалвнмх сбоев. В зтом разделе мм поговорим как раз о таких сбонх. А также 
о том, почему считаетсл допустиммм игнорироватв такие ситуации. Кроме того, 
н опишу несколвко проблем, которме могут возникнутЂ, если не обрагцатЂ внимангш 
на зти сбои, и предложу пути решенгш. 

ОбЂектно-ориентированное программирование позволлет добитвсл от раз- 
работчиков вмсокои продуктивности. Изриднан заслуга тут принадлежит компо- 
зиционнмм удобствам, облегчагогцим написание, чтение и редактирование кода. 
Например, рассмотрим строку: 

Boolean f = "Deff".Substring(l, 1).ToUpper().EndsWith("E"); 

Вклгочаи в программу такуго инструкциго, разработчик делает важное допугцение 
о том, что ее вмполнение проидет без ошибок. Однако ошибкгг вполне возможнм, и 
нам нужен способ борвбм с ними. Длн зтого и сугцествугот конструкторм и механиз- 
мм обработки исклгочении, ивлигогциеси алвтернативои методам из Win32 и СОМ, 
возврагцагогцим значение true или f alse в зависимости от резулвтата своеи работм. 

ПродуктивностЂ разработки достигаетсл не толђко благодари композицион- 
ности кода, но и благодари некотормм возможностим компилиторов. В частности, 
компилнтор способен неивно: 

□ вставлитЂ в вмзмваемми метод необнзателвнее параметрм; 

□ упаковмватЂ зкземплнрм значимого типа; 

□ создаватЂ и инициализироватЂ массивм параметров; 

□ свнзмватЂСи с членами динамических переменнмх и вмражении; 

□ свнзмватЂСи с методами расширенин; 

□ свнзмватЂСи с перегруженнмми операторами и вмзмватЂ их; 

□ создаватЂ делегатм; 

□ автоматически определнтв тип при вмзове обобгценнмх методов, обЂнвлении 
локалЂнмх переменнмх и исполЂЗОвании лнмбда-вмражении; 

□ определлтв и создаватЂ классм заммкании (closure) длл лимбда-вмражении 
и итераторов; 

□ определлтЂ, создаватЂ и инициализироватЂ анонимнме типм и их зкземплирм; 
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□ писатћ код поддержки LINQ (Language Integrated Queries). 

Да и CLR делает многое длн облегченин жизни программистов. К примеру, CLR 
умеет неивно: 

□ ББ13Б1ватБ виртуалБНБШ и интерфеиснБШ методБ1; 

□ загружатБ сборки и Ј1Т-компилируемБ1е методБ 1 , которвге могут статк ис- 
точником исклгочении FileLoadException, BadImageFormatException, 
InvalidProgramException, FieldAccessException, MethodAccessException, 
MissingFieldException, MissingMethodException и VerificationException; 

□ пересекатБ границ,Б1 домена приложении длл доступа к обвектам типа, произ- 
водного от MarshalByRefObject, которвге могут статв источником исклгоченин 

AppDomainUnloadedException; 

□ сериализоватБ и десериализоватБ обвектБ1 при пересечении границ домена 
приложении; 

□ заставлитБ поток генерироватБ исклгочение ThreadAbortException при вБ130ве 
методов Thread.Abort и AppDomain.Unload; 

□ ББ 13 Б 1 ватБ методБ1 Finalize, что 6 б 1 сборгцик мусора до освобождешш памити 
обвекта вбшолнил завершагогцие операции; 

□ создаватв типб 1 в куче загрузчика при работе с обобгценнвши типами; 

□ ББ13БшатБ статическии конструктор типа, которкп! может статк источником ис- 
клгоченгш TypeInitializationException; 

□ генерироватБ различнБге исклгоченил, в том числе OutOfMemoryException, 
DivideByZeroException, NullReferenceException, RuntimeWrappedException, 
TargetInvocationException,OverflowException, NotFiniteNumberException, 
ArrayTypeMismatchException, DataMisalignedException, IndexOutOfRange- 
Exception,InvalidCastException,RankException,SecurityException и многие 
другие. 

И, разумеетсл, .NET Framework поставллетсл с обширнои библиотекои клас- 
сов, содержагцих деслтки тбгсич типов, каждвги из которБ1х поддерживает обгцуго, 
многократно исполвзуемуго функционалБностБ. Многие из зтих типов предна- 
значенБ 1 длл создангш веб-приложении, веб-служб, приложении с расширеннвш 
полБЗОвателБСКим интерфеисом, приложении длн работкг с системои безопасности, 
длл управленгш изображенгшми, длл распознавангш речи — зтот список можно 
продолжатв бесконечно. И лгобаи частк кода зтих приложении может статк источ- 
ником ошибки. В следугогцих версгшх могут понвитбси новбш типбг исклгочении, 
наследугогцие от уже сугцествугогцих. И ваши блоки catch начнут перехватвшатв 
исклгоченгш, о которпх ранкше и не подозревали. 

Все зто вместе — обБектно-ориентированное программирование, средства ком- 
пилитора, функционалБностБ CLR и грандиознаи библиотека классов — делагот 
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.NET Framework столб привлекателБнои платформои длн разработки программного 
обеспеченгш 1 . Но н хочу сказатБ, что все зто нвлнетсл потенциалБНБш источником 
ошибок, которБ 1 е mki практически не можем контролироватБ. Пока программа 
работает, все хорошо: mbi легко пишем код, которвш также легко читаетсл и ре- 
дактируетсл. Но как толбко случаетсн сбои, оказкшаетсл, что поннтб, где именно 
произошла ошибка и в чем ее причина, практически невозможно. Вот пример, 
иллгострируклции сказанное: 

private static Object OneStatement(Stream stream, Char charToFind) { 
return (charToFind + " + stream.GetType() + String.Empty 

+ (stream.Position + 512M)) 

.Where(c=>c == charToFind).ToArray(); 

} 


Зтот немного неестественнБп) метод содержит всего одну инструкциго на С#, 
но зта инструкцин решает сразу несколвко задач. Вот IL -код, сгенерированнБ1и 
компилитором C# длл зтого метода (места потенциалБНБ1х сбоев, обусловленнвге 
неивно вБшолннемБши операцгшми, вБвделенБ! полужирнБш шрифтом): 


.method private hidebysig static object OneStatement( 

class [mscorlib]System.10.Stream stream, char charToFind) cil managed { 
,maxstack 4 
.locals init ( 

[0] class Program/oc_DisplayClassl V_0, 

[1] object[] V_l) 

IL_0000: newobj instance void Program/oc_DisplayClassl:: .ctor() 

IL_0005: stloc.0 
IL_0006: ldloc.0 
IL_0007: ldarg.l 

IL_0@08: stfld char Program/oc_DisplayClassl: :charToFind 

IL_0@0d: ldc.i4.5 

IL_000e: newarr [mscorlib]System.Object 

IL_0@13: stloc.l 

IL_0014: ldloc.l 

IL_0015: ldc.i4.0 

IL_0016: ldloc.0 

IL_0017: ldfld char Program/oc_DisplayClassl: :charToFind 

IL_001c: box [mscorlib]System.Char 

IL_0@21: stelem.ref 

IL_0022: ldloc.l 

IL_0023: ldc.i4.1 

IL_0@24: ldstr ": " 

IL_0029: stelem.ref 
IL_002a: ldloc.l 
IL 002b: ldc.i4.2 


1 Мне следовало сказатБ, что столб привлекателБнои длн разработчиков платформу делагот 
етце и редактор Visual Studio, механизм IntelliSense, возможностб работБ 1 с фрагментами кода, 
шаблонБ1, расширлемостБ, отладчик и многое другое. Но л вБ1нес зто за пределБ! основного 
обсужденил, так как зти средства не влилгот на поведение кода во времл ввшолненил. 
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IL_002c: ldang.0 
IL 002d: 


callvirt instance class [msconlib]System.Type [mscorlib]System.Object::GetType() 


IL_0032: 
IL_0033: 
IL_0034: 
IL_0035: 
IL_003a: 
IL_0@3b: 
IL_0@3c: 
IL_003d: 
IL_003e: 
IL_0043: 

IL_0048: 

IL_004d: 
IL 0052: 


stelem.ref 
ldloc.l 
ldc.i4.3 

ldsfld string [mscorlib]System.String::Empty 

stelem.ref 

ldloc.l 

ldc.i4.4 

ldarg .0 

callvirt instance int64 [mscorlib]System.IO.Stream::get_Position() 

call valuetype [mscorlib]System.Decimal 

[mscorlib]System.Decimal::op_Implicit(int64) 

ldc.i4 0x200 

newobj instance void [mscorlib]System.Decimal::.ctor(int32) 

call valuetype [mscorlib]System.Decimal [mscorlib]System.Decimal:: 

op_Addition 


(valuetype [mscorlib]System.Decimalj 
valuetype [mscorlib]System.Decimal) 

IL_0057: box [mscorlib]System.Decimal 

IL_005c: stelem.ref 
IL_005d: ldloc.l 

IL_005e: call string [mscorlib]System.String::Concat(object[]) 

IL_0@63: ldloc.0 

IL_0064: ldftn instance bool Program/oc_DisplayClassl::<OneStatement>b_0(char) 

IL_006a: newobj instance 

void [mscorlib]System.Func'2<charj bool>::.ctor(objectj native int) 
IL_006f: call class [mscorlib]System.Collections.Generic.IEnumerable'1<!!0> 
[System.Core]System.Linq.Enumerable::Where<char>( 
class [mscorlib]System.Collections.Generic.IEnumerable'1<!!0>, 
class [mscorlib]System.Func'2<!!0, bool>) 

IL_0074: call !!0[] [System.Core]System.Linq.Enumerable::ToArray<char> 

(class [mscorlib]System.Collections.Generic.IEnumerable'1<!!0>) 

IL 0079: ret 


} 


Как видите, исклгочение OutOfMemoryException может 6 мтб сгенерировано 

в процессе созданин класса <>с_ DisplayClassl (тип генерируетсл компилнтором), 

массива Object [ ], делегата Func, атакжепри упаковкетипов char и Decimal. Вну- 
треннее вмделение памнти происходит при вмзове методов Concat, Where и ТоАггау. 
Создание зкземплнров типа Decimal может сопровождатБСн вбгоовом конструктора 
зтого типа, что может статћ причинои исклгоченин T^pelnitializationEKception 1 . 
Затем неивно вБ 13 Б 1 ваготсн операторнБге методБ1 op_Implicit и op_Addition типа 
Decimal, которнго могут делатк что угодно, в том числе и генерироватв исклгочение 
OverflowException. 


1 Кстати, конструкторм классов длл типов System.Char, System.String, System.Type 
и System.IO.Stream в зтом приложении также могут статв причинои исклкзченил 
TypeInitializationException, причем при аналогичннх обстолтелБствах. 
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Интерес также представлиет обрашение к своиству Position класса Stream. 
Начнем с того, что зто виртуалћное своиство, позтому метод OneStatement не 
«знает», какои код на самом деле следует вмполнчтб, что может привести к лгобому 
исклгочениго. Кроме того, так как класс Stream происходит от класса Marshal- 
ByRefObject, аргумент stream может ссшлатБСл на обЂект-представителг., сам 
ивлигогциисн ссмлкои на обвект другого домена приложении. Но другои домен 
приложении может оказатБСи вБ1груженнБ1м, что ведет к поивлениго исклгоченил 
AppDomainUnloadedException. 

И конечно, все вБ13БшаемБ1е методБ1 мне совершенно неподконтролБНБ1, потому 
что они написанБ 1 разработчиками из Microsoft. Зато не исклгочено, что в будугцем 
специалистБ 1 Microsoft поменчгот их реализациго, а зто приведет к hobbim типам 
исклгочении, о которБ 1 х ц на момент написанин метода OneStatement не подозре- 
вал. Разве возможно сделатв зтот метод загцшценнвш от всех возможнбш ошибок? 
Кстати, проблемБ 1 создает и противоположнан ситуацил: блок catch способен пере- 
хватвшатБ типб 1 исклгочении, порожденнкге конкретнБш типом, позтому возможно 
вБшолнение кода восстановленгш совсем длл другои ошибки. 

Теперв, получив информациго о возможнб 1 х ошибках, вбц скорее всего, сами 
можете ответитв на вопрос, почему считастси допустимвш написание неустоичи- 
вого и ненадежного кода — просто учитвшатБ все возможнбго ошибки непрактично. 
Более того, nopoii зто вообгце невозможно. Также следует учитвшатБ тот факт, что 
ошибки возникагот относителвно редко. И позтому 6 б 1 ло решено пожертвоватБ 
надежностБго кода в угоду продуктивности работБ1 программистов. 

Исклгоченгш хороши егце и тем, что необработаннвге исклгоченил приводит 
к аваргшному завершениго приложенгш. И зто здорово, так как многие проблемБ 1 
ВБ 1 ИВЛЧГОТСН егце на стадии тестированил. Информацгш, которуго bbi при зтом 
получаете (сообгцение об ошибке и трассировка стека), обвшно достаточно длл 
внесенгш нужнвгх исправлении. Разумеетсн, еств и фирмБц не желагогцие, что 6 б 1 
их приложенгш авариино завершалисв в ходе тестировангш или исполБЗОвангш, 
позтому разработчики вставлнгот код, перехватБшагогции исклгочение типа System . 
Exception, базового длм всех типов исклгочении. Другое дело, что при таком под- 
ходе возможнБ1 ситуации, когда приложение продолжит работу с испорченнБш 
состоинием. 

ЧутБ позже мбг рассмотрим класс Account, определлгогции метод Transfer 
длн перевода денег с одного счета на другои. Представвте, что при вБгзове зтого 
метода денвги успешно вБгчитаготсл с одного счета, но перед зачислением их на 
другои счет генерируетсл исклгочение. Если вБгзБгвагогции код перехватБгвает ис- 
клгоченил типа System . Exception и продолжает работу, состоиние приложенгш 
окажетсн испорченнмм: как на счете f rom, так и на счете to будет менвше денег, 
чем там должно 6бгтб. А так как в данном случае мбг говорим о денвгах, порча со- 
стоингш рассматриваетсн уже не как обкгчнаи ошибка, а как проблема системм 
безопасности приложенгш. Продолжал работу, приложение вбгполнит егце рид 
переводов с одного счета на другои, а значит, порча состоингш в рамках прило- 
женгш продолжитсл. 
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Можно сказатБ, что метод Т ransf en должен сам перехватБшатБ исклгоченин типа 
System . Exception и возвратцатБ денБги на счет f nom. Зто деиствителБно сработает 
длл более-менее простого метода Tnansfen. Но если он производит контролвнБш 
отчет ИЗБНТБ 1 Х денег или если со счетом одновременно работает несколвко потоков, 
попБ1тка отменитБ операцшо уже не будет иметн успеха, а толбко приведет к ново- 
му исклгоченшо. А зто значит, что ситуацин не улучшитси, а толбко ухудшитсн. 

ПРИМЕЧАНИЕ 

Можно возразитБ, что информациз о месте возникновении ошибки важнеесведении 
о ее содержании. Например, полезнее 6бшо бм знатБ, что переводденегсо счета не 
произошел, а нето, что MeTOflTransfer несработал из-заисклкзченил SecurityException 
или OutOfMemoryException. На самом деле, моделБ обработки ошибок Win32 деи- 
ствуетследукзгцим способом: методБ! возвраидшотзначение true или false, указБ 1 вал 
на резулБтативностБ своеи работм. Зто дает вам информацикз о том, какои именно 
метод стал причинои проблемм. Затем, если в программе предусмотрен поиск ин- 
формации о причинахсбол, вБ13Б1ваетсл метод GetLastError. В кпассе System.Exception 
присутствует своиство Source, указБ 1 вакзш,ее имл незавершенного метода. Но зто 
своиство принадлежит ктипу String, позтому вам придетсл самостолтелБно анализи- 
роватБ полученнме даннБ 1 е. Ктомуже в ситуации, когда два метода вмзмвакзт один и 
тотже метод, своиство Source не поможет вам понлтб, где именно произошел сбои. 
Вместо зтого придетсл анализироватБ строку, возвраиденнукз своиством StackTrace 
класса Exception. Из-за всех зтих сложностеи л пока еш,е не встречал программиста, 
написавшего подобнми код. 


Сугцествугот несколкко подходов, способних сгладитв проблему испорченного 
состоннии: 

□ CLR запрегцает авариино завершатв потоки во времи вБшолненгш кода блоков 
catch и finally. Позтому сделатв метод Tnansfen более устоичивБш можно 
следугогцим способом: 

public static void Transfer(Account from, Account to, Decimal amount) { 
try { /* здесБ ничего не делаетсн */ } 
finally { 

from -= amountj 

// Прермвание потока (из-за Thread.Abort/AppDomain.Unload) 

// здесБ невозможно 
to += amount; 

} 

} 

Тем не менее и настоителБно не рекомендуго помегцатБ весБ код внутрк 
блоков finally! Зтот приемможно исполвзоватБ толбко длл измененинсамнгх 
чувствителБНБгх состоннни. 

□ Класс System . Diagnostics . Contnacts . Contnact позволиет применнтБ к методам 
контрактБг кода. Именно они позволнгот провернтв аргументБг и другие пере- 
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меннме перед модификациеи состоишш с исполБЗОванием зтих аргументов/ 
переменнмх. В случае соответствин контракту веролтностЂ повреждешш со- 
СТОНН1Ш минималБна (но не невозможна). Если же проверка не проходит, сразу 
генерируетсл исклгочение. Контрактм будут более рассмотренм далее в зтои главе. 

□ Области ограниченного исполненгш (CER) дагот возможностб избежатБ имего- 
гцихсл в CLR неоднозначностеи. К примеру, перед входом в блок tny можно 
загрузитБ все требуемвге кодом соответствугогцих блоков catch и finally сбор- 
ки. Кроме того, CLR скомпилирует весв код блоков catch и f inally, вклгочаи 
вБгзвгваемБге внутри зтих блоков методвг. Таким способом можно устранитБ 
множество потенциалвнБгх исклгочении (в том числе FileLoadException, 
BadImageFormatException,InvalidProgramException,FieldAccessException, 
MethodAccessException,MissingFieldException и MissingMethodException), 
которвге могут возникнутБ при попБгтке вБшолненгш кода восстановленгш после 
ошибок (в блоках catch) или кода очистки (в блоке f inally). Также зто снизит 
веронтностБ понвленгш исклгоченгш OutOf Метогу Exception и некоторвгх других. 
Области ограниченного исполненгш подробно обсуждаготсл в зтои главе. 

□ В зависимости от местоположенгш состоингш можно исполвзоватБ транзакции, 
гарантиругогцие, что в состонние вноситси либо весв пакет изменении, либо оно 
остаетсл неизменнБгм. К примеру, транзакции хорошо подходлт длл храненгш 
даннБгх в базе. Windows в настонгцее времн также поддерживает транзакционнвге 
операции с реестром и фаилами (толбко длн томов NTFS), так что вбг можете 
восполБЗОватБСи зтими функцгшми. К сожалениго, в настонгцее времц в .NET 
Framework даннаи функционалБноств не представлена. Дли исполБЗОванин 
зтих операции потребуетсл исполвзоватБ механизм P/Invoke. ДополнителБ- 
нуго информациго по даннои теме вбг наидете в документации класса System. 
Transactions.TransactionScope. 

□ Можно сделатв методБг более нвнбши. К примеру, класс Monitor обкшно исполб- 
зуетси длн вклгоченгш/отклгоченгш блокировки при синхронизации потока: 

public static class SomeType { 

private static Object s_myLockObject = new Object(); 
public static void SomeMethod () { 

Monitor.Enter(s_myLockObject); // B случае исклтченил произоидет ли 

// блокировка? Если да, то зтот режим 
// будет невозможно отклтчитв! 

try { 

// Безопаснал в отношении потоков операцил 

} 

finally { 

Monitor . Exit(s_myLockObject) ; 

} 

} 

II ... 

} 
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Из-за описаннмх проблем не стоит исполћзоватћ зтот вариант перегрузки 
метода Enter класса Monitor. Лучше переписатБ код следуклцим образом: 

public static class SomeType { 

private static Object s_myLockObject = new Object(); 

public static void SomeMethod () { 

Boolean lockTaken = false; // Предполагаем, что блокировки нет 
try { 

// Зто работает вне зависимости от наличиа исклтченив! 

Monitor.Enter(s_myLockObject, ref lockTaken); 

// Потокобезопаснан операцин 

} 

finally { 

// Если режим блокировки вклтчен, отклтчаем его 
if (lockTaken) Monitor . Exit(s_myLockObject) ; 

} 

} 

П ... 

} 

Хотл зтот код стал более прозрачнкш, в случае блокировки в рамках синхро- 
низации потоков лучше вообгце не прибегатв к обработке исклгочении. ПричинБ 1 
зтого рассматриваготсн в главе 30. 

Если обнаружитсл, что состонние 6бшо повреждено настолвко, что уже не под- 
лежит восстановлениго, его надлежит удалитв, что6б1 не создаватБ новб1х проблем. 
Затем перезапустите приложение, что6б1 состонние инициализировалосБ нормалБно. 
Если повезет, повреждение состоннгш не произоидет снова. Так как управлиемое 
состонние не может вбгходитб за грашшш домена приложении, длн устраненгш по- 
врежденнБгх состоннии достаточно вБггрузитБ домен приложенин, восполБЗОвавшисБ 
методом Unload класса AppDomain (детали см. в главе 22 ). 

Если вбг считаете, что состоиние повреждено настолвко, что остаетсл толб- 
ко завершитБ весБ процесс, исполБзуите статическии метод FailFast класса 
Environment: 

public static void FailFast(String message); 

public static void FailFast(String message, Exception exception); 

Зтот метод завершает процесс без вБгполненгш активнБгх блоков try/f inally 
и без вбгзовов метода Finalize. Ведв вБгполнение дополнителБного кода в по- 
врежденном состоннии может ухудшитв положение дел. Тем не менее метод 
FailFast дает возможностб вбгполнитб очистку обвектам, производнБгм от класса 
CriticalFinalizerObject, с которкгми мбг познакомимсн в главе 21 . Обвгчно зто 
нормалвно, так как зти о6ђ6ктбг стремнтсн просто закрнгтБ исходнБге ресурсБг. К тому 
же состоиние Windows, скорее всего, останетсн в поридке даже при повреждении 
состоингш CLR или вашего приложенгш. Метод FailFast записвшает сообгцение 
в журнал собвгтии Windows, после чего вклгочает зто сообгцение в отчет об ошибках. 
Затем он создает дамп памнти вашего приложенгш и завершает его работу. 
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ВНИМАНИЕ 

По болишеи части FCL -код не гарантирует сохраненич нормалиного состоннич по- 
сле неожиданного исклкзченич. При обнаружении исклкзченип, прошедшего через 
FCL -код, продолжение работн с FCL-o6beKTaMH повншает вероптноств их непред- 
сказуемого поведенип. 


В отом разделе п попмталсн познакомитћ вас с возможнмми проблемами, свнзан- 
нмми с механизмом обработки исклгочении в CLR. Болбшинство приложении не 
стоит исполБЗОватБ при повреждении их состоннин, так как зто ведет к понвлениго 
некорректнмх даннмх и даже дефектов в системе безопасности. Если вм пишете 
приложение, которое не может авариино завершатБ свого работу (например, опе- 
рационнуго систему или ндро 6a.3i>i даннћгх), не стоит исполћзоватБ управлиемБги 
код. И так как система Microsoft Exchange Server написана в основном средствами 
управлнемого кода, длн храпепии злектроннои почтбг она задеиствует собственнуго 
базу даннБгх. Зта база назБшаетсн Extensible Storage Engine, она поставлнетсн вместе 
с Windows и обвшно располагаетсн по адресу C:\Windows\System32\EseNT.dll. При 
желании вбг можете восполБЗОватБСи зтои базои дли своих приложении. 

УправлиемБги код хорошо подходит длн приложении, которпге могут перенести 
прекрагцение работБ 1 при возможном повреждении состоинии. В зту категориго 
попадает множество приложении. Написатв собственнуго устоичиво работагогцуго 
библиотеку классов или приложение краине сложно, именно позтому в болвшинстве 
случаев разработчики предпочитагот обходитвсн управлиемБш кодом, повБгшан 
продуктивностБ своеи работвг. 


Приемн работм с исклк>ченилми 

ПониматБ механизм обработки исклгочении важно, но не менее важно уметв 
правилБно полБЗОватБСи исклгоченгшми. Слишком часто н встречал библиотеки, 
которвге перехватвшали все исклгочешш без разбора и оставлнли разработчика при- 
ложенгш в неведении о возникшем сбое. В зтом разделе н предлагаго рекомендации 
по исполвзованиго исклгочении, которвге должен знатв каждБш разработчик. 

ВНИМАНИЕ 

Если Bbi — разработчикбиблиотекклассов и занимаетесБСОЗданием типов, которме 
будут исполБЗОватБ другие разработчики, отнеситесБ кзтим правилам оченБсерБез- 
но. На вас лежит огромнал ответственносљ за разработку интерфеиса, применимого 
кширокому спектру приложении. Помните: вм незнаете всехтонкостеи кода, которми 
вмзБ 1 ваете через делегатм, а также через виртуалБнме или интерфеиснме методм. 
Вм также не знаете, какои код будет Bbi3biBaTb вашу библиотеку. Невозможно пред- 
видети все ситуации, в котормх может применлтисл ваш тип, позтому не принимаите 
никаких политических решении. Ваш код не должен решати, что ести ошибка, а что 
нет — оставкте зто решение Bbi3biBaiOL4eMy коду. 
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Внимателнно следите за состолнием и стараитеси избежатБ его поврежденил. Про- 
верлите аргументв!, передаваемв 1 е вашим методам, с noMombio контрактов (см. 
далее в зтои главе). Стараитеси не изменлтБ состолние без необходимости, а если 
изменлете — будете готовм к сболм и последукош,ему восстановленико состолнил. 
Если вм будете соблкздаш рекомендации, изложеннне в зтои главе, у разработчиков 
приложении не будет особмх проблем с исполизованием типов вашеи библиотеки 
классов. 

Если bw — разработчик приложении, определлите лкобуко политику, какуко сочтете 
нужнои. ПридерживачсБ правил разработки, bn сможете бмстрее вб 1 пвлптб и ис- 
правлатБОшибки в своем коде, что повв 1 Ситустоичивоств ваших приложении. Однако 
Bbi BoabHbi отходит^ от зтих правил, если после тпдателвного обдумнванил сочтете 
зто необходимим. Политику приложенил (например, более arpeccnBHbin перехват 
исклкзчении кодом приложенил) определлете именно ви. 


Активно исполвзуите блоки finally 

По-моему, блоки finally — прекрасное средство! Они позволнгот определлтБ код, 
которми будет гарантированно исполнен независимо от вида сгенерированного 
потоком исклгоченгш. Блоки f inally нужнм, чтобм вмполнитб очистку после лго- 
бои успешно начатои операции, прежде чем вернутБ управление или продолжитв 
исполнение кода, расположенного после них. Блоки f inally также часто исполб- 
зуготси длн нвного уничтоженгш лгобвгх обЂектов с целБГО предотврагценгш утечки 
ресурсов. В следугогцем примере в зтом блоке размегцен весв код, вбшолннгогции 
очистку (закрБшагогции фаил): 

using System; 
using System.IO; 

public sealed class SomeType { 
private void SomeMethod() { 

// Открмтие фаила 

FileStream fs = new FileStream(@"C: \Data .bin ", FileMode.Open); 
try { 

// Вивод частного от деленил 100 на первии баит фаила 
Console.WriteLine(100 / fs . ReadByte() ); 

} 

finally { 

// B блоке finally размецаетсл код очистки, гарантируклции 
// закритие фаила независимо от того, возникло исклгачение 
// (например, если первми баит фаила равен 0) или нет 
fs . Close( ); 

} 

} 

} 

Гарантированное исполнение кода очистки при лгобвгх обстолтелБСтвах настолв- 
ко важно, что болвшинство нзБгков поддерживает соответствугогцие программнвге 
конструкции. Например, в C# при исполБЗОвании инструкции lock, using и foreach 
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блоки tny/f inally создаготси автоматически. Компилнтор строит зти блоки и при 
переопределении деструктора класса (метод Finalize). При работе с упомннутмми 
конструкцилми написаннБШ вами код помепдаетсл в блок try, а код очистки — в блок 
finally. А именно: 

□ если Bbi исполБзуете инструкциго lock, то внутри блока finally снимаетсл 
блокировка; 

□ если Bbi исполБзуете инструкциго using, то внутри блока f inally длл обвекта 
вмзмваетси метод Dispose; 

□ если вм исполБзуете инструкциго f oreach, то внутри блока f inally длл обвекта 
IEnumerator вмзмваетсл метод Dispose; 

□ если вм определлете деструктор, то внутри блока finally вмзмваетсл метод 
Finalize базового класса. 

Например, в следугогцем коде на C# исполБзуготсл возможности инструкции 
using. Хотл зтот фрагмент короче предмдугцего, при обработке исходного текста 
зтого и предмдугцего примеров компилптор генерирует идентичнми код: 

using System; 
using System.I0; 

internal sealed class SomeType { 
private void SomeMethod() { 
using (FileStream fs = 

new FileStream(@"C: \Data .bin", FileMode.Open)) { 

// Внвод частного от деленин 100 на первни баит фаила 
Console.WriteLine(100 / fs . ReadByte( )); 

} 

} 

} 

Подробнее об инструкции using мм поговорим в главе 21, а об инструкции 
lock — в главе 30. 


Не надо перехватмватв все исклк)ченил 

Распространеннан ошибка — слишком частое и неуместное исполБЗОвание бло- 
ков catch. Перехватмван исклгочение, вм тем саммм заивлнете, что ожидали его, 
понимаете его причинм и знаете, как с ним разобратБСл. Другими словами, вм 
определлете политику длл приложенин. Зта тема подробно раскрмта в разделе 
«ПродуктивностБ вместо надежности». 

Тем не менее слишком часто приходитси видетБ примерно такои код: 

try { 

// Попмтка вћшолнитБ код, KOTopbiii, как считает программистЈ 
// может привести к сбокк .. 

} 
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catch (Exception) { 


} 

Зтот код демонстрирует, что в нем предусмотренм все исклгоченгш лтбвос типов 
и он способен восстанавливатвси после лчобих исклгочении в лтбих ситуациих. 
Разве зто возможно? Тип из библиотеки классов ни в коем случае не должен пере- 
хватмватБ все исклгоченгш подрлд: ведБ он не может знатг> наверннка, как при- 
ложение должно реагироватБ на исклгоченгш. Кроме того, такои тип будет часто 
вБгзБгватБ код приложенгш через делегата, виртуалБНБш метод или интерфеиснБш 
метод. Если в однои части приложенгш возникает исклгочение, то в другои части, 
веронтно, еств код, спосо6нбш перехватитБ его. Исклгочение должно проити через 
филБтр перехвата и 6бггб передано вверх по стеку вбгзовов, чтобвг код приложенгш 
смог обработатв его как надо. 

Если исклгочение осталосн необработаннБгм, CLR завершает процесс. О необ- 
работаннвгх исклгоченгшх мбг поговорим чутв позже. Болбшинство из них обнару- 
живаготси на стадии тестировангш. Дли борвбвг с ними следует либо заставитв код 
реагироватБ на определенное исклгочение, либо переписатБ его, устранив условгш, 
ставшие причинои сбон. Число необработаннвгх исклгочении в окончателвнои 
версгш программвг, предназначеннои длл вБгполненгш в производственнои сре- 
де, должно 6бгтб минималБНБш, а сама программа должна 6бгтб исклгочителБно 
устоичивои. 

ПРИМЕЧАНИЕ 

В некоторБ 1 х случаах метод, не способнБ 1 и решитБ поставленнуко задачу, обнару- 
живает, что состолние некоторнх обЂектов испорчено и не поддаетсч восстановле- 
нико. Если разрешитБ приложенико продолжитБ работу, резулБтатБ! могут оказатБса 
плачевнмми, в том числе возможно нарушение безопасности. При обнаружении 
такои ситуации метод должен не генерироватБ исклкочение, а немедленно вмпол- 
нлтб принудителБное завершение процесса вшовом метода FailFast типа System. 
Environment. 


Кстати, вполне допустимо перехватитв исклгочение System. Exception и вбг- 
полнитб определеннБш код внутри блока catch при условгш, что в конце зтого кода 
исклгочение будет сгенерировано снова. Перехват и поглогцение (без повторного 
генерировангш) исклгоченгш System . Exception недопустимо, так как оно приводит 
к сокрвгтиго факта сбои и продолжениго работнг приложенгш с непредсказуемБши 
резулБтатами, что означает нарушение безопасности. Предоставлиеман компаниеи 
Microsoft утилита FxCopCmd.exe позволнет находитв блоки catch (Exception), 
в коде которвгх отсутствует инструкцгш throw. Подробнее мбг обсудим зто далее 
в зтои главе. 

Наконец, допускаетсл перехватитв исклгочение, возникшее в одном потоке, 
и повторно сгенерироватБ его в другом потоке. Такое поведение поддерживает 
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моделБ асинхронного программировании (см. главу 28). Например, если поток из 
пула потоков вБшолниет код, которБш вБ13Бшал исклгочение, CLR перехватБшает 
и игнорирует исклгочение, позволнн потоку вернутвсл в пул. Позже один из потоков 
должен вБ13ватв метод EndXxx, что 6 б 1 вбшснитб резулБтат асинхроннои операции. 
Метод EndXxx сгенерирует такое же исклгочение, что и поток из пула, вБшолннвшего 
заданнуго работу. В даннои ситуации исклгочение поглогцаетсл перввш потоком, но 
повторно генерируетси потоком, ввгоБшавшим метод EndXxx, в резулвтате ошибка 
не оказБ1ваетси скрвпои от приложенгш. 


Корректное восстановление после искл>оченив 


Иногда заранее известно, источником какого исклгоченгш может статв метод. По- 
сколБку зти исклгоченин ожидаемБ1 заранее, нужен код, обеспечивагогции корректное 
восстановление приложенгш в такои ситуации и позволигогции ему продолжитв 
работу. Вот пример (на псевдокоде): 


public String CalculateSpreadsheetCell(Int32 row, Int32 column) { 
String result; 
try { 

result = /* Код длл расчета значенил лчеики злектроннои таблицћ! */ 

} 

catch (DivideByZeroException) { 

result = "Нелцзл отобразитц значение: деление на нолц"; 


} 

catch (OverflowException) { 

result = "Нелцзл отобразитц значение: оно слишком болцшое"; 


} 


return result; 


} 


Зтот псевдокод рассчитвшает содержимое нчеики злектроннои таблицБг и воз- 
врагцает строку с ее значением вБгзвшагогцему коду, которкш показБшает его в окне 
приложенгш. Однако содержимое нчешси может 6 бгтб чдстнбш от деленгш значенгш 
двух других нчеек. И если лчеика со знаменателем содержит 0, то CLR генерирует 
исклгочение DivideByZeroException. Тогда метод перехватвшает именно зто ис- 
клгочение и возврагцает специалБнуго строку, котораи вбшодитсл полБЗОвателго. 
Аналогично содержимое ччеики может 6 бгтб произведением двух других лчеек. 
Если полученное значение не умегцаетсл в отведенное число битов, CLR генерирует 
обвект Overf lowException, а также специалвнуго строку, котораи будет вБшедена 
дли полБЗОвателл. 

ПерехватБгваи конкретнвге исклгоченгш, нужно полностбго осознаватБ вбгзбг- 
вагогцие их обстолтелвства и знатв типбг исклгочении, производнБге от перехватБг- 
ваемого типа. Не следует перехватвшатБ и обрабатБгватБ тип System. Exception 
(без повторного генерировангш), так как невозможно предвидетв все возможнвге 
исклгоченгш, которвге могут 6 бгтб сгенерированБг внутри блока try (особенно зто 
касаетсч типов OutOfMemoryException и StackOverflowException). 
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Отмена незавершеннмх операции 
при невосстановиммх исклк>ченивх 

Обмчно дли вмполненин единственнои абстрактнои операции методу приходитси 
вмзмватБ несколБКО других методов, одни из котормх могут завершатБСн успешно, 
а другие — нет. Допустим, происходит сериализацгш набора обвектов в фаил. После 
сериализации 10 обЂектов генерируетсл исклгочение (например, из-за переполненин 
диска или из-за отсутствин атрибута Serializable у следугогцего сериализуемого 
обвекта). После зтого исклгочение филБтруетсл и передаетсн вБгзБгвагогцему методу, 
но в каком состоннии остаетсн фаил? Он оказвгваетсн поврежденнБгм, так как в нем 
находитсн частично сериализованнБш граф обЂектов. Ббшо 6бг здорово, если 6 бг 
приложение могло отменитБ незавершеннБге операции и вернутБ фаил в состонние, 
в котором он 6 бш до записи сериализованнБгх обЂектов. ПравилБнаи реализацгш 
должна ББгглндетБ примерно так: 

public void SerializeObjectGraph(FileStream fs^ 

IFormatter formatter, Object rootObj) { 

// Сохранение текушеи позиции в фаиле 

Int64 beforeSerialization = fs.Position; 

try { 

// Попитка сериализоватц граф обцекта и записатц его в фаил 
formatter . Serialize(fs, rootObj ); 

} 

catch { // Перехват всех исклтчении 

// При ЛИБОМ повреждении фаил возвратаетсл в нормалцное состолние 
fs.Position = beforeSerialization; 

// Обрезаем фаил 
fs.SetLength(fs . Position) ; 

// ПРИМЕЧАНИЕ: предмдушии код не помешен в блок finally, 

// так как сброс потока требуетсл толцко при сбое сериализации 

// Уведомллем вмзмваккции код о происходлшем, 

// снова генерирул TO ЖЕ САМОЕ исклтчение 
throw; 

} 


Длн корректнои отменБг незавершеннБгх операции код должен перехватБшатБ все 
исклгоченгш. Да, здесв нужно перехватБгватБ все исклгоченгш, так как важен не тип 
ошибки, а возврагцение структур даннвгх в согласованное состолние. Перехватив 
и обработав исклгочение, не поглогцаите его — вБгзБшагогцему коду необходимо со- 
обгцитБ о ситуации. Зто делаетсл путем повторного генерировангш того же исклго- 
ченгш. В C# и многих других нзвгках зто осугцествлнетсн просто: просто укажите 
клгочевое слово throw без продолженгш, как в предвгдугцем фрагменте кода. 
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Обратите внимание, что в предмдуш,ем примере не указан тип исклгоченил 
в блоке catch, посколбку здесБ требуетсл перехватБшатБ абсолготно все исклгоче- 
нип. К счастБГО, в C# достаточно опуститв тип исклгоченин, и инструкции throw 
повторно сгенерирует зто исклгочение. 


Сокрмтие деталеи реализации длл сохраненил контракта 

Иногда бвшает полезно после перехвата одного исклгочешш сгенерироватБ исклго- 
чение другого типа. Зто может 6 б 1 тб необходимо длн сохранешш смпшла контракта 
метода. Тип нового исклгоченил должен 6 б 1 тб конкретнБш (не исполБЗОватБСл 
в качестве базового или лгобого другого типа исклгочении). Рассмотрим псевдокод 
типа PhoneBook, определнгогцего метод поиска номера телефона по имени: 

internal sealed class PhoneBook { 

private String m_pathname; // ПутБ к фаилу c телефонами 

// В|> 1 полнение других методов 

public String GetPhoneNumber(String name) { 

String phone; 

FileStream fs = null; 
try { 

fs = new FileStream(m_pathname, FileMode.Open); 

// Чтение переменнои fs до обнаруженил нужного имени 
phone = /* номер телефона наиден */ 

} 

catch (FileNotFoundException е) { 

// Генерирование другого исклгоченил, содержашего имл абонента, 

// с заданием исходного искличенил в качестве внутреннего 
throw new NameNotFoundException(name, е); 

} 

catch (I0Exception e) { 

// Генерирование другого исклтченил, содержашего имл абонента, 

// с заданием исходного исклкзченил в качестве внутреннего 
throw new NameNotFoundException(name, е); 

} 

finally { 

if (fs != null) fs.Close(); 

} 

return phone; 

} 

} 


ДаннБ 1 е телефонного справочника получагот из фаила (а не из сетевого соеди- 
ненгш или базБ1 даннБ1х), но полБЗОвателго типа PhoneBook зто неизвестно, так как 
зто — особенностБ реализации, котораи может изменитксл в будугцем. Позтому, 
если почему-либо фаил не наиден или не может 6б1тб прочитан, вБ13Б1вагогции 
код получит исклгочение Filel\lotFoundException или IOException, которое он 
не ожидает. Иначе говорп, сугцествование фаила и возможностб его чтенин не 
пвлпготсл частБГО ненвного контракта метода; тот, кто вБ13вал зтот метод, не может 
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знатћ заранее, что зти допушении будут нарушенм. Позтому метод GetPhoneNumber 
перехватмвает зти два типа исклгочении и генерирует вместо них новое исклгочение 

NameNotFoundException. 

При исполвзовании зтого приема следует перехватмватБ конкретнме исклго- 
чении, обстоителБСтва возникновении котормх вм хорошо понимаете. Кроме того, 
вм должнм знатБ, какие типм исклгочении ивлиготсн производнмми от перехва- 
тмваемого типа. 

Повторное генерирование исклгоченгш сообгцает вмзмвагогцему коду о том, что 
метод не в состоннии решитБ свого задачу, а тип NameNotFoundException дает ему 
абстрактное представление о причине сбои. Важно задатБ внутреннее исклгочение 
нового исклгочешш как имегогцее тип FileNotFoundException или IOException, 
чтобвг не потеритБ его реалБнуго причину, знание которои может 6бгтб полезно 
разработчику типа PhoneBook. 

ВНИМАНИЕ 

ИсполБзуп описаннБш подход, Mbi обманмваем вмзБ 1 ва! 01 ции код в двухотношениах. 
Во-первих, Mbi искажаем информацикзотом, что пошло нетак. В нашем примере фаил 
не удалоси наити, но мм сообш,или о невозможности наити имл. Во-втормх, Mbi пере- 
даем невернукз информацикз о месте сбол. Если 6w исклкзчение FileNotFoundException 
могло пробитисл наверх стека визовов, его своиство StackTrace говорило 6bi, что 
ошибка произошла в конструкторе FileStream. Flo когда мм поглош,аем зто исклкз- 
чение и генерируем новое NameNotFoundException, трассировка стека укажет, что 
ошибка произошла в блоке catch, то есљ на расстолнии несколиких строк кода от 
места генерированин исклкзченич. Зто может сериезно затрудниљ отладку, позтому 
onncaHHbin подход следует исполБЗОваш с осторожносшкз. 


А теперБ предположим, что тип PhoneBook 6бш реализован чутн иначе. Пустн он 
поддерживает открвгтое своиство PhoneBookPathname, позволигогцее полвзователго 
задаватв или получатБ ими и путБ к фаилу, в котором нужно искатв номер телефо- 
на. ПосколБку полБЗОвателБ знает, что даншле телефонного справочника берутси 
из фаила, и модифицируго метод GetPhoneNumber так, чтобвг он не перехватвшал 
никакие исклгоченгш, а вншускал их за пределБг метода. ЗаметБте: и мениго не па- 
раметрнг метода GetPhoneNumber, а способ его абстрагированного представленгш 
полвзователим типа PhoneBook. В резулвтате полБЗОватели будут ожидатв, что путБ 
предусмотрен контрактом PhoneBook. 

Иногда генерирование нового исклгоченгш после перехвата уже имегогцегоси 
преследует целвго добавление к исклгочениго новбгх ддннбгх или контекста. Однако 
:зта целБ достигаетси намного прогце. Достаточно перехватитБ исклгочение нужного 
вам типа, добавитв в коллекциго его своиства Data требуемуго информациго и сге- 
нерироватв его заново: 

private static void SomeMethod(String filename) { 
try { 

// Какие-то операции } 
catch (IOException e) { 


продолжение & 
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// Добавление имени фаила к обиекту IOException 
e.Data.Add("Filename"j filename); 

thnow; // повторное генерирование того же исклгаченил 

} 

} 


Хорошии практическии пример: если конструктор типа генерирует иск. по- 
чение, которое не перехватБ 1 ваетсл внутри его метода, зто исклгочение пере- 
хватв 1 вает своими средствами CLR, а вместо него генерирует исклгочение 
TypeInitializationException. Зто полезно, так как CLR создает внутри методов 
код ненвного ввиова конструкторов типа 1 . Если конструктор типа генерирует ис- 
клЈОчение DivideByZeroException, ваш код может попБ1татБСл перехватитБ его 
и восстановитБСн. При зтом вб 1 даже не узнаете о том, что бмл задеиствован кон- 
структор типа. А так как CLR преобразует исклгочение DivideByZeroException 
в TypeInitializationException, bbi четко видите, что причинои исклгоченин стали 
проблемБ 1 с конструктором типа, а не с вашим кодом. 

Впрочем, и зтот подход имеет и свои недостатки. При ввгоове метода через 
отражение CLR автоматически перехватвшает все генерируемвге зтим методом 
исклгоченгш и преобразует их тип в TargetInvocationException. В резулвта- 
те длл поиска сведении о причинах исклгоченгш требуетсл перехватитв обвект 
TargetInvocationException и проанализироватБ его своиство InnerException. 
Более того, при работе с отражешшми, как правило, приходитсл иметв дело при- 
мерно с таким кодом: 

private static void Reflection(Object o) { 

try { 

// Вмзов метода DoSomething длл зтого обБекта 
var mi = o.GetType().GetMethod("DoSomething"); 

mi.Invoke(o, null); // Метод DoSomething может сгенерироватБ исклтчение 

} 

catch (System.Reflection.TargetInvocationException e) { 

// CLR преобразует его в TargetInvocationException 

throw e.InnerException; // Повторнал генерацил исходного исклтченил 

} 

} 


Впрочем, все не так плохо. Если дли ввгзова члена исполвзуготсл примитивнБге 
динамические типбг C# (о них мбг говорили в главе 5), сгенерированнБш компилнто- 
ром код не перехватБшает вообгце никаких исклгочении и не генерирует исклгочение 
TargetInvocationException; исходное сгенерированное исклгочение просто пере- 
мегцаетси вверх по стеку. Именно позтому многие разработчики вместо отражении 
предпочитагот исполвзоватБ примитивнБге динамические типбг. 


1 ДополнителБнуго информацшо по зтои теме вбг наидете в соответствуЈошем разделе 
главБг 8. 
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Необработаннне исклк>ченил 

Итак, при поивлении исклгоченин CLR начинает в стеке вмзовов поиск блока 
catch, тип которого соответствует типу исклгоченин. Если ни один из блоков catch 
не отвечает типу исклгочешш, возникает необработанное исклтчение (unhandled 
exception). Обнаружив в процессе поток с необработаннмм исклгочением, CLR 
немедленно уничтожает зтот поток. Необработанное исклгочение указмвает на 
ситуациго, которуго не предвидел программист, и должно считатБСл признаком 
серћезнои ошибки в приложении. На зтом зтапе о проблеме следует уведомитБ 
компаниго, где разработано приложение, что6б1 авторБ1 могли устранитБ неполадку 
и вБшуститБ исправленнуго версиго. 

Разработчикам библиотек классов не нужно даже думатв о необработаннБ 1 х ис- 
клгоченгшх. О них должнб 1 заботитБСн толбко разработчики приложении, которкш 
в приложении следует реализоватв политику, определигогцуго порлдок обработки 
необработаннБ 1 х исклгочении. Microsoft рекомендует разработчикам приложении 
просто приннтБ политику CLR, предлагаемуго по умолчаниго. То естк в случае не- 
обработанного исклгочешш Windows создает записв в журнале системнвш со 6 б 1 тии. 
Что 6 б 1 просмотретБ его, откроите приложение Event Viewer и переидите к узлу 
Windows Logs-^Application, как показано на рис 20.1. 


в 
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Рис. 20.1. Журнал Windows Event с информациеи о приложении, 
работа которого бнла завершена из-за необработанного исклкзченил 


ДополнителБнуго информациго о проблеме можно получитн в приложении Win- 
dows Reliability Monitor, запускаемом из панели управлешш Windows. В нижнеи 
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части окна приложенин, как показано на рис. 20.2, можно увидетБ список прило- 
жении, закрћшшихсл из-за необработаннБ 1 х исклгочении. 



Рис. 20.2. Приложение Reliability Monitor с информациеи о приложенилх, 
3aKpbiTbix из-за необработаннмх исклкзчении 



Рис. 20.3. Приложение Reliability Monitor с дополнителинои информациеи 

о сболх приложении 
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Дли получентш еше более подробнои информации следует дваждм нделкнутБ 
на имени приложенин в нижнеи части журнала Reliability Monitor. Пример полу- 
ченнмх таким способом сведении показан на рис. 20.3, а расшифровку полеи можно 
наити в табл. 20.2. Все необработаннме исклкзченин, полученнме в управлиеммх 
приложенинх, iioMcmaiOTca в контеинер CLR20r3. 


Таблица 20.2. Сигнатурн проблем 


Номер 

полл 

Описание 

01 

Имл исполнлемого фаила (ограничение 32 знака) 

02 

Версил сборки исполнлемого фаила 

03 

Временнан отметка исполннемого фаила 

04 

Полное имн сборки исполннемого фаила (ограничение 64 знака) 

05 

Версил авариинои сборки 

06 

Временнаи отметка авариинои сборки 

07 

Тип и метод авариинои сборки. Зто метка метаданнв 1 х MethodDef (после усе- 
ченил верхнего баита 0x06), обозначакмцал метод, ставшии причинои исклго- 
ченил. Знал зто значение, можно наити проблемнв^е тип и метод с помотцбго 
ILDasm.exe 

08 

IL -код некорректного метода. Взнв величину смепгенил внутри зтого кода, 
при помшци ILDasm.exe можно наити некорректнБ 1 и код 

09 

Тип сгенерированного исклгоченил (ограничение 32 знака) 


После фиксации информации о некорректном приложении Windows вмводит 
диалоговое окно, позволнгогцее полБЗОвателго отправитБ информациго об ошибке 
в Microsoft 1 . Даннми механизм информировангш об ошибках назмваетсн Windows 
Еггог Reporting. ДополнителБнуго информациго о его работе вбг можете получитБ 
на саите Windows Quality ( http://WinQual.Microsoft.com ). 

При желании компании могут зарегистрироватБСн в Microsoft и получатв ин- 
формациго об ошибках своих приложении и компонентов. Подписка бесплатна, 
но толбко при условии, что сборки удостоверенБг подписбго VeriSign Ш (другое 
название — подписб издателн ПО дли Authenticode). 

Впрочем, вб1 вправе разработатв собственнуго систему полученгш информации 
о необработаннБгх исклгоченгшх, необходимуго длн устраненгш недостатков про- 
граммБг. При инициализации приложенгш можно проинформироватБ CLR, что естБ 


1 Чтобм запретитл полвление окна сообшенил, исполБзуите P/Invoke длл ВБгзова функции 
Win32 SetErrorMode с передачеи значенил SEM_NOGPFAULTERRORBOX. 
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метод, которми нужно вшзмватћ каждБ 1 и раз, когда в каком-либо потоке возникает 
необработанное исклгочение. 

К сожаленшо, в разнБ 1 х моделих приложении Microsoft исполБзуготси раз in>ic 
спосо 6 б 1 получении доступа к информации необработаннБ 1 х исклгочении. Можно 
исполБЗОватБ следугогцие членБ 1 FCL (подробнее см. документациго): 

□ Дли многих приложении — собБггие UnhandledException класса System.App- 
Domain. Приложенин Windows Store и Microsoft Silverlight не могут обрашатксн 
к зтому со6б1тиго. 

□ Длл приложении Windows Store — собнтш UnhandledException класса Win- 
dows.UI.Xaml.Application. 

□ Длл приложении Windows Forms — виртуалБНБш метод OnThreadException 
класса System.Windows. Forms .NativeWindow, одноименнБпг виртуалБНБш метод 
класса System.Windows . Forms .Application исобБ 1 тие ThreadException класса 
System.Windows.Forms.Application. 

□ Длл приложении Windows Presentation Foundation (WPF) — собктге 
DispatcherUnhandledException класса System.Windows .Application, a также 
со6б1тил UnhandledException и UnhandledExceptionFilter класса System. 
Windows.Threading.Dispatcher. 

□ Длл приложении Silverlight — собБ 1 тие UnhandledException класса System. 
Windows.Application. 

□ Длл приложении ASP.NET Web Form — собБггие Error класса System.Web. 
UI.TemplateControl. Класс TemplateControl — базовкш длл System.Web. 
Ul.Page и System.Web.UI.UserControl. Кроме того, можно задеиствоватБ со- 
бБггие Error класса System.Web.HTTPApplication. 

□ Длл приложении Windows Communication Foundation — своиство ErrorHandlers 
класса System.ServiceModel.Dispatcher.ChannelDispatcher. 

B завершение темБ1 хотелосБ 6 б 1 сказатБ несколБКО слов о необработаннБ1х 
исклгоченгшх, которнге могут произоити в распределеннвгх приложенгшх, таких 
как веб-саитБг и веб-службБг. В идеалБном мире серверное приложение, в котором 
случилосБ необработанное исклгочение, зарегистрирует сведенгш об исклгочении 
в журнале, уведомит клиента о невозможности вБгполненгш запрошеннои опе- 
рации и завершит свого работу. Но мбг живем в реалвном мире, в котором может 
оказатБСи невозможнБгм отправитБ уведомление клиенту. На некоторвгх серверах, 
поддерживагогцих даннвге состоннин (таких как, например, Microsoft SQL Server), 
непрактично останавливатБ сервер и запускатв его заново. 

В серверном приложении информациго о необработанном исклгочении нелвзи 
возврагцатБ клиенту, так как ему от зтих сведенгш мало полбзбг, особенно если кли- 
ент создан другои компаниеи. Более того, сервер должен предоставлнтв клиентам 
как можно менБше информации о себе самом, так как зто снижает вероитностБ 
успешнои хакерскои атаки. 
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ПРИМЕЧАНИЕ 

В CLR некоторме исклкзченил, генерируемие машинннм кодом, рассматривакзтсл 
как исклкзченил поврежденного состолнич (Corrupted State Exceptions, CSE). Дело 
в том, что odbNHO они нвллкзтсн следствием проблем с CLR или с машиннмм кодом, 
неподконтролвнв 1 х разработчику. По умолчаникз CLR не позволлет управллемому 
коду nepexBaTbiBaTb такие исклкзчении и блок finally не виполнлетсн. Вот список 
CSE -исклкзчении eWin32. 


EXCEPTION_ACCESS_VIOLATION 

ЕХСЕ PTION_STACK_OVE RFLOW 

EXCEPTION_ILLEGAL_INSTRUCTION 

EXCEPTION_IN_PAGE_ERROR 

EXCEPTION_INVALID_DISPOSITION 

EXCEPTION_NONCONTINUABLE_EXCEPTION 

EXCEPTION_PRIV_INSTRUCTION 

STATUS_UNWIND_CONSOLIDATE 


OTflenbHbie управллемне методв! могут перегружати методер предлагаемне 
по умолчаникз, и перехвативатв зти исклкзченин, применпп к методу атрибут 
System.Runtime.ExceptionServices.HandleProcessCorruptedStateExceptions- 
Attribute. Кроме того, к методу должен 6biTb применен атрибут System.Security. 
SecurityCriticalAttribute. Можно перегрузитн MeTOflbi, предлагаемне по умолчаникз 
длп всего процесса, присвоив алементу legacyCorruptedStateExceptionPolicy в кон- 
фигурационном ХМЕ-фаиле приложенип значение true. CLR преобразует 6oab- 
шинство етих исклкзчении в обвект System.Runtime.lnteropServices.SEHException. 
TonbKO исклкзчение EXCEPTION_ACCESS_VIOLATION преобразуетсл в očteKTSvstem. 
AccessViolationException, а искпкзчение EXCEPTION_STACK_OVERFLOW— в обвект 
System .StackOverflowException . 


ПРИМЕЧАНИЕ 

Перед Bbi 30 B 0 M метода можно восполвзоваљсл методом EnsureSufficientExecutionStack 
класса RuntimeHelper длч проверки количества свободного места в стеке длч визова 
«среднего» метода (которни не имеет четкого определенин). Если места в стеке 
недостаточно, метод генерирует исклкзчение lnsufficientExecutionStackException, 
которое bw можете перехватитш Метод EnsureSufficientExecutionStack не принимает 
аргументов и возврашдет значение типа void. 06bi4HO он применчетсл с рекурсив- 
HbiMH методами. 


Отладка исшиочении 

В отладчике из Microsoft Visual Studio естћ ciieiina.ii.iiaM поддержка исклкзчении: 
вмберите команду Exceptions в менкз Debug — поивитси диалоговое окно, показан- 
ное на рис. 20.4. 
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Рис. 20.4. Диалоговое окно Exceptions с различнв 1 ми исклкзченилми 


ЗдесБ показанБ 1 типб 1 исклгочении, поддерживаемБ 1 е Visual Studio. Раскригв 
ветвБ Common Language Runtime Exceptions, как показано на рис. 20.5, вбг увидите 
пространства имен, поддерживаемБге отладчиком из Visual Studio. 



Рис. 20.5. С1Р-искл10ченил, упорлдоченнБ 1 е по пространствам имен, 
в диалоговом окне Exceptions в Visual Studio 


Раскркш пространство имен, как показано на рис. 20.6, m>i увидите все опреде- 
леннБге в нем типбг, производнБге от System . Exception. 

Если длп какого-либо исклгоченин установлен флажок Thrown, при генерации 
зтого исклгоченин отладчик остановитсл. В момент останова среда CLR егце не 
приступила к поиску подходнгцего блока catch. Зто может 6бгтб полезно длп от- 
ладки кода, ответственного за перехват и обработку соответствугогцего исклгочешш. 
Также зто может пригодитвсл в ситуации, когда bbi подозреваете, что компонент 
или библиотека поглогцает или повторно генерирует исклгочение, и не знаете, где 
поставитв точку останова, что6б1 застатБ компонент «на месте преступлешш». 

Если длл исклгоченин флажок Thrown не установлен, отладчик остановитсл, 
толбко если после понвленгш соответствугогцего исклгоченгш оно останетсл необ- 
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работаннмм. Зто наиболее популирнми вариант, так как обработанное исклгочение 
означает, что приложение предвидит возникновение подобнмх исклгочении и знает, 
как с ними справлитБСн. 



Рис. 20.6. Диалоговое окно Exceptions в Visual Studio с CLR -исклизчениими, 
определеннмми в пространстве имен System 

Bbi можете определитБ собственнБге типб1 исклгочении и добавлитБ их в окно, 
нделкнув на кнопке Add. При зтом поивлнетсл диалоговое окно, показанное на 
рис. 20.7. 



Рис. 20.7. Передача Visual Studio сведении о собственном типе исклизчении 

В зтом окне сначала вБ 1 бирагот тип Common Language Runtime Exceptions, a затем 
вводлт полное имн собственного типа исклгочении. Вводимбп! тип не обизателБно 
должен 6б1тб потомком System. Exception, так как типбр не совместимБШ с CLS, 
поддерживаготсн в полном обвеме. Если у вас два или болБше типов с одинаковБши 
именами, но в разнвш сборках, различитБ зти типб1 невозможно. К счастБГО, такое 
случаетси редко. 

Если в вашеи сборке определенБ1 несколБКО типов исклгочении, следует добав- 
лнтб их по очереди. И 6bi хотел, что6б1 в следугогцеи версии зто диалоговое окно 
позволлло находитБ сборку и автоматически импортироватв из нее в отладчик 
Visual Studio все типб1, производнБге от Exception. А возможностб дополнитслбнои 
идентификации каждого типа по имени сборки решила 6bi проблему одноименнБ1х 
типов из разнБ1х сборок. 
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СкоростБ обработки исклкзчении 

В сообтцестве программистов вопросм бмстродеиствин, свизаннме с обработкои 
исклгочении, обсуждаготси оченв часто и активно. Некоторме полБЗОватели счи- 
тагот зту процедуру настолБКО медленнои, что отказБшаготси к неи прибегатБ. Но 
и утверждаго, что длл обБектно-ориентированнои платформБ1 обработка исклгоче- 
нии обизателБна. Собственно, чем ее можно заменитв? Неужели вб 1 предпочтете, 
что6б1 методБ1 возврагцали значение true или f alse, чтобвг сообгцатв об успехе 
или неудаче своеи работвг? Или восполБзуетесБ кодом ошибок типа enum? В зтом 
случае m>i столкнетеск с худшими сторонами обоих решении. CLR и код библиотек 
классов будут генерироватв исклгоченин, а ваш код начнет возврагцатв код ошибок. 
В итоге вам все равно придетсн вернутвси к необходимости обработки исклгочении. 

Трудно сравниватБ бБгстродеиствие механизма обработки исклгочении и более 
привБшнБгх средств уведомленин об исклгоченгшх (возврагценин значенин HRESULT, 
специалБНБгх кодов и т. п.). Если вбг напишете код, которкги сам будет проверитБ 
значение, возврагцаемое каждвш вБгзваннБш методом, филБтроватБ и передаватБ его 
коду, вБгзвавшему метод, то бвгстродеиствие приложенгш сервезно снизитсл. Даже 
если оставггтв бБгстродеиствие в стороне, обвем дополнителБного кодированггн гг по- 
тенциалБнан возможностб ошибок окажутсл неподБемнБгми. В такои обстановке 
обработка исклгочении вбгглидит намного лучшеи алБтернативои. 

Неуправлиемвгм компиллторам С++ приходитсл генерироватБ код, отслежи- 
вагогции успешное создание обвектов. Компилнтор также должен генерироватв код, 
которкги при перехвате исклгоченин вБгзвгвает деструктор длн каждого из успешно 
созданнвгх обвектов. Конечно, здорово, что компшштор принимает зту рутину на 
себл, однако он генерирует в приложении слишком много кода длл веденгш вну- 
треннеи <<бухгалтерии» обвектов, что негативно влгшет как на обвем кода, так и на 
времл исполненгш. 

В то же времн управлнемвгм компилнторам намного легче вести учет обвектов, 
посколБку памнтБ длл управлиемБгх обвектов вБгделнетсл из управлиемои кучи, 
за которои следит уборгцик мусора. Если обвект 6бгл успешно создан, а затем воз- 
никло исклгочение, уборгцик мусора, в конечном счете, освободит памлтв, занцтуго 
обвектом. Компилнтору не приходитсл генерироватБ код длл внутреннего учета 
успешно созданнвгх обвектов гг последугогцего ввгзова деструктора. Зто значит, что 
в сравнении с неуправлиемвгм кодом на С++ компшштор генерирует менкше кода, 
менБше кода обрабаткгваетси и во времн вБгполнении, в резулвтате бБгстродеиствие 
приложенгш растет. 

За прошедшие годбг мне приходилосБ полБЗОватБСи обработкои исклгочении на 
многггх нзБгках, в различнБгх ОС гг в системах с разнвгми архитектурами процессора. 
В каждом случае обработка исклгочении бкгла реализована по-своему, со своими 
достоинствами и недостатками. В некоторвгх случанх конструкции, обрабатвгваго- 
гцие исклгоченин, компилируготсл прнмо в метод, а в других даннвге, свизаннБге 
с обработкои исклгочении, храпмтси в свнзаннои с методом таблице, к которои об- 
рагцаготсн толбко пргг возникновенигг исклгочении. Одни компилнторБг не способннг 
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вмполннтб подстановку кода методов, содержатцих обработчики исклгочении, другие 
не регистриругот переменнме, если в методе естБ обработчик исклгочении. 

СутБ в том, что нелБЗи оценитБ величину дополнителБнмх издержек, которме 
влечет за собои обработка исклгочении в приложении. В управлнемом мире сделатБ 
такуго оценку егце труднее, так как код сборки может работатБ на лгобои платформе, 
поддерживагогцеи .NET Framework. Так, код, сгенерированнБш Ј1Т-компиллтором 
длл обработки исклгочении на машине х86, будет силбно отличатБСн от кода, сгенери- 
рованного JIT -компилнтором в системах с процессором IA64 или Ј1Т-компилнтором 
из .NET Compact Framework. 

Мне все же удалосБ протестироватБ некоторБ1е мои программБ1 с разнБ1ми 
JIT -компилиторами производства Microsoft, предназначеннБши дли внутреннего 
исполБЗОвангш. И неожиданно обнаружил огромнуго разницу в бБгстродеиствии. 
Отсгода следует, что нужно тестироватв свои код на всех платформах, на которвгх 
предполагаетсл его применнтв, и вноситб соответствугогцие измененгш. И в зтом 
случае н 6 бг не беспокоилсн о снижении бБгстродеиствгш из-за обработки исклго- 
чении. Как н уже отмечал, полвза от обработки исклгочении намного перевешивает 
зто снижение. 

Если вам интересно, насколвко обработка исклгочении снижает производителБ- 
ностб вашего кода, исполвзуите встроеннБпг монитор производителБности Windows. 
ПоказаннБш на рис. 20.8 снимок зкрана демонстрирует счетчики, свизаннБге с обра- 
боткои исклгочении, которкге устанавливаготси при установке .NET Framework. 








Рис. 20.8. Счетчики исклкзчении .NET CLR в окне монитора производителБности 


Времи от времени попадаетсл какои-нибудв часто вБ13Б1ваемБш метод, которБпг 
активно генерирует исклгоченгш. В такои ситуации снижение производителБности 
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из-за обработки слишком частмх исклгочении оказмваетсл оченБ значителБнмм. 
В частности, в Microsoft слмшали от несколћких клиентов жалобм, что при вмзове 
метода Parse класса Int32 и передаче некорректнмх даннмх, введеннмх конечнмми 
полвзователими, возникал сбои. Так как метод Parse вмзмвалси часто, генерацин и 
перехват исклгочении серћезно снижали обгцуго производителБностБ приложенгш. 

Длн решенин заивленнои клиентами проблемм и в соответствии с принципами, 
описаннмми в зтои главе, специалистм Microsoft добавили в класс Int32 метод 
TryParse, имегогции две перегруженнме версии: 

public static Boolean TryParse(String s, out Int 32 result); 
public static Boolean TryParse(String s, NumberStyles styles, 

IFormatProvider, provider, out Int 32 result); 

Как видите, все зти методм возврагцагот значение типа Boolean, указмвагогцее, 
содержит ли переданнаи строка символм, которме можно преобразоватБ в Int32. 
Зти методБ 1 также возврагцагот вбшоднои параметр result. Если методБ 1 возвра- 
гцагот значение true, параметр result содержит резулвтат преобразовангш строки 
в 32-разридное целое. В противном случае зтот параметр оказвшаетсл равен 0, но 
зто значение врнд ли может исполБЗОватБСи в коде. 

И 6bi хотел абсолготно четко пронснитБ одну вегцБ: возврат методом ТгуХхх 
значенгш f alse указвшает на один и толбко один тип сбои. Длл других сбоев метод 
может генерироватБ исклгоченгш. Например, метод Т ryParse класса Int32 в случае 
передачи неверного параметра генерирует исклгочение ArgumentException. И ко- 
нечно же, он может сгенерироватв исклгочение OutOfMemoryException, если при 
вБгзове TryParse происходит ошибка ввгделешш памнти. 

Также хотелосБ 6бг подчеркнутБ, что обБектно-ориентированное программи- 
рование повБпнает производителБностБ труда программиста, и не последним фак- 
тором ивлиетси запрет на передачу кодов ошибок в членах типов. Иначе говори, 
конструкторвг, методБг, своиства и пр. создаготсл с расчетом на то, что в их работе 
сбоев не будет. И при условии правилвности определенгш в болвшинстве случаев 
при исполБЗОвании типов сбоев не будет, а значит, не будет сниженгш производи- 
телвности, обусловленного исклгоченгшми. 

Типбг и их членБг следует определнтБ так, чтобкг свести к минимуму веронтноств 
их сбоев в стандартнвгх сценаргшх их исполБЗОвангш. Если вбг позже услБгшите 
от своих клиентов, что из-за ввгдачи множества исклгочении производителвностБ 
неудовлетворителБна, тогда и толбко тогда имеет смбгсл подуматБ о добавленгш 
в тип методов ТгуХхх. Иначе говори, сначала надо создатв оптималБнуго обвект- 
нуго моделБ, а затем, если полБЗОватели окажутсл недоволвнБгми, добавитБ в тип 
несколвко методов Т гуХхх, которвге облегчат им жизнб. Тем же, кто не испБггБшает 
проблем с производителБностБго, лучше продолжитБ работатБ с исходнои версиеи 
типа, потому что она имеет более совершеннуго обвектнуго моделв. 
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Области ограниченного вБтолненич 

Во многих приложенинх не нужнм вмсокан надежностБ и способностћ к восстанов- 
леншо после лгобмх сбоев. Зто относитси, прежде всего, к клиентским приложени- 
нм — например, Notepad.exe и Calc.exe. Многие из нас сталкивалисБ с ситуациеи, 
когда приложенгш из пакета Microsoft Office — WinWord.exe, Excel.exe и Outlook. 
ехе — просто завершагот свого работу из-за необработаннмх исклгочении. Также 
многие сервернме приложенин (например, веб-серверм) не имегот долгосрочного 
состоншш и в случае необработаннмх исклгочении автоматически перезагружа- 
готсл. Конечно, длл некотормх серверов (например, SQ,L Server) потери даннмх 
в подобнмх случалх намного более критична. 

В CLR информацгш о состоннии хранитсн в классе AppDomain (подробно он 
рассмотрен в главе 22). Его вмгрузка сопровождаетсл вмгрузкои всего состоннгш. 
Соответственно, если поток в домене приложении сталкиваетсл с необработаннмм 
исклгочением, можно вмгрузитБ домен (удалив все состоишш), не завершаи всего 
процесса 1 . 

Областг>к) ограниченного внтолненил (Constrained Execution Region, CER) на- 
ЗБшаетсн фрагмент кода, которнш должен 6бгтб устоичивбш к сболм. Так как до- 
менБ1 приложении допускагот внггрузку с уничтожением своего состоншш, области 
ограниченного ввшолнешш обншно служат длн управленин состопнием, обгцим длн 
несколвких доменов или процессов. Особенно они полезнБц если вбг собираетесБ 
работатБ с состоннием, в котором возможнбг неожиданнБге исклгоченгш. Такие ис- 
клгоченгш иногда назБгвагот асинхронними (asynchronous exceptions). Например, 
длл вмзова метода среда CLR должна загрузитв сборку, создатв тип обвекта в куче 
загрузчика домена приложении, ввгзватв статическии конструктор типа, скомпи- 
лироватБ IL -код в машиннвш код и т. п. Сбои может произоити в ходе лгобои из 
зтих операции, и CLR оповестит об зтом при помогци исклгоченгш. 

Если лгобои такои сбои произоидет в блоке catch или finally, код восста- 
новленгш или очистки будет ввшолнен не полностбго. Рассмотрим пример кода, 
в котором возможен сбои: 

private static void Demol() { 

try { 

Console.WriteLine("In try"); 

} 

finally { 

// Нелвнми внзов статического конструктора Typel 

Typel.M(); 

} 

} 


1 Зто верно длл случаев, когда поток не вбгходит за пределБ! одного класса AppDomain 
(подобно тому, как ASP.NET и управлпемБШ SQL-cepeep храннт сценарии процедур). Но 
длл потоков, пересекакнцих границв! домена пргшожении, может потребоватБсн завершение 
работБ!. 
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private sealed class Typel { 
static Typel() { 

// B случае исклгаченил M не внзмваетсл 
Console.WriteLine("Typel ' s static ctor called"); 

} 

public static void M() { } 

} 


Вот резулБтат работБ 1 зтого кода: 

In try 

Typel's static ctor called 

Нам нужно, что 6 б 1 код в блоке tny вбшолннлсн толбко при условии ввшолнешш 
кода в свнзаннБ 1 х с ним блоках catch и f inally. Длн зтого код следует переписатБ 
так: 

private static void Demo2() { 

// Подготавливаем код в блоке finally 

RuntimeHelpers . PrepareConstrainedRegions( ); // Пространство имен 

// System.Runtime . CompilerServices 

try { 

Console.WriteLine("In try"); 

} 

finally { 

// Ненвнни BbBOB статического конструктора Type2 
Type2.M(); 

} 


public class Type2 { 
static Type2() { 

Console.WriteLine("Type2's static ctor called"); 

} 

// ИсполБЗуем атрибут, определеннми в пространстве имен 
// System.Runtime.ConstrainedExecution 

[ReliabilityContract(Consistency.WillNotCorruptState, Cer.Success)] 
public static void M() { } 

} 


После запуска зтои версии кода получаем: 

Type2's static ctor called 
In try 

Метод PrepareConstnainedRegions играет особуго ролв. Обнаружив его перед 
блоком try, JIT -компилитор немедленно начинает компилироватв соответству- 
кнцис блоки catch и finally. JIT -компиллтор загружает лгобвге сборки, создает 
лгобв 1 е типб1, вБ13Бшает лгобв 1 е статические конструкторБ 1 и компилирует лгобвге 
методБ 1 . Если хотл 6 б 1 одна из зтих операции дает сбои, исклгочение возникает до 
входа потока в блок try. 
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В процессе подготовки методов JIT -компилитор просматривает весв граф вм- 
зовов. Однако обрабатнвает он толбко методм, к котормм бмл применен атрибут 
ReliabilityContnactAttnibute со значенгшми параметра Consistency равнмми 
WillNotConnuptState или Consistency . MayConnuptInstance, так как длн методов, 
которме могут повредитБ домен приложении или состонние процесса, CLR не 
дает никаких гарантии. Нужно гарантироватБ, что внутри загцигцаемого методом 
PnepaneConstnainedRegions блока catch или finally будут вБгзБшатвсн толбко 
методБг с настроеннБгм, как показано в предвгдугцем фрагменте кода, атрибутом 
ReliabillityContnactAttnibute. 

Вот как вБггллдит зтот атрибут: 

public sealed class ReliabilityContractAttribute : Attribute { 
public ReliabilityContractAttribute( 

Consistency consistencyGuarantee, Cer cer); 
public Cer Cer { get; } 

public Consistency ConsistencyGuarantee { get; } 

} 

Он дает разработчику возможностб указатБ степенБ надежности отделБного 
метода 1 . Типбг Cen и Consistency относлтсл к перечисленгшм и определлготсл 
следугогцим образом: 
enum Consistency { 

MayCorruptProcess, MayCorruptAppDomain, 

MayCorruptInstance, WillNotCorruptState 

} 

enum Cer { None, MayFail, Success } 

Если ваш метод гарантированно не может повредитв состонние, исполпзуите 
значение Consistency .WillNotConnuptState. В противном случае ввгберите одно 
из трех других значенгш в зависимости от степени его надежности. Длл метода 
с гарантированно успешнвш завершением исполвзуите значение Cen.Success. 
В противном случае ввгбираите параметр Cen . MayFail. Лгобои метод, дли которого 
не определен атрибут ReliabilityContnactAttnibute, можно считатк помеченнБш 
таким вот образом: 

[ReliabilityContract(Consistency.MayCorruptProcess, Cer . None)] 

Значение Cen.None указвгвает, что никаких CER -гарантии в данном случае не 
даетси. Другими словами, метод может завершитвси неудачно и даже не сообгцитБ 
об зтом. Помните, что болБшинство зтих параметров дагот методу возможностб 
проинформироватБ вБгзБшагогцуго сторону, чего от него можно ожидатБ. CLR и JIT- 
компшштор зти сведенгш игнориругот. 

Чтобвг написатБ надежнБпг метод, делаите его как можно менкше по размеру 
и ограничиваите сферу его деиствгш. Убедитесв, что там не вБгделлетсл памнтБ под 


1 Атрибут можно применитБ также к интерфеису, конструктору, структуре, классу или 
сборке. 
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обЂектм (например, не вмполннетсл упаковка), не вмзмваите внутри ни вирту- 
алЂнмх, ни интерфеиснмх методов, не полћзуитесБ делегатами или отраженинми, 
так как в зтом случае JIT -компилитор не сможет определитБ, какои именно метод 
вБ13Б1ваетси на самом деле. Можно даже вручнуго подготовитб все методБ 1 при по- 
могци одного из следугогцих методов класса RuntimeHelpers: 

public static void PrepareMethod(RuntimeMethodHandle method) 

public static void PrepareMethod(RuntimeMethodHandle method, 

RuntimeTypeHandle[] instantiation) 
public static void PrepareDelegate(Delegate d); 

public static void PrepareContractedDelegate(Delegate d); 

Имеите в виду, что ни компилитор, ни CLR не провернгот гарантии, которвге 
вб1 даете, снабжаи свои метод атрибутом ReliabiltyContractAttnibute. Если вбг 
что-то перепутали, состонние вполне может оказатвси поврежденнБш. 

ПРИМЕЧАНИЕ 

Даже хорошо подготовленнвш метод может статв источником исклкзченип 
StackOverflowException. Если среда CLR не внполнлетсл в размеиденном (hosted) 
режиме, искпкзчение StackOverflowException приводит к немедленному завершеникз 
процесса путем внутреннего Bbi30Ba метода Environment.FailFast. Если же среда 
работает в размеиденном режиме, метод PreparedConstrainedRegions проверчет, 
осталосв ли в стеке хотл 6bi 48 Кбаит свободного места. При ограниченном месте 
в стеке исклкзчение StackOverflowException генерируетсп до начала блока try. 


Не следует забБгватБ и про метод ExecuteCodeWithGuaranteedCleanup класса 
RuntimeHelper, которБш предоставлиет егце одну возможностб вБшолненин кода 
с гарантированнои очисткои: 

public static void ExecuteCodeWithGuaranteedCleanup( 

TryCode code, CleanupCode backoutCode, Object userData); 

При ввгзове зтого метода вбг передаете тело блоков try и finally в качестве 
методов обратного ввгзова, прототипБ1 которБгх соответствугот зтим двум делегатам: 

public delegate void TryCode(Object userData); 

public delegate void CleanupCode(Object userData, Boolean exceptionThrown); 

Упомину егце один способ гарантированного ввгполненгш кода. Зто класс 
CriticalFinalizerObject, которБпг подробно рассмотрен в следугогцеи главе. 


KoHTpaKTbi кода 

Контрактм кода (code contracts) — зто механизм декларативного документировангш 
решении, принитБгх в ходе проектировангш кода, внутри самого кода. Контрактвг 
бБгвагот трех видов: 
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□ предусловил (preconditions) исполћзуготсн длн проверки аргументов; 

□ постусловил (postconditions) служат длл проверки состопнин завершенин метода 
вне зависимости от того, нормалБно он завершилси или с исклгочением; 

□ uueapuaumbi (object invariants) позволнгот удостоверитБСи, что даннме обвекта 
находлтсч в хорошем состоннии на всем протлжении жизни зтого обвекта. 

Контрактм облегчагот исполБЗОвание кода, его понимание, разработку, тестирова- 
ние 1 , документирование и распознавание ошибок на ранних стадилх. Предусловин, 
постусловгш и инвариантм можно представитБ в виде части сигнатурм методов. 
При зтом вм можете ослабитБ контракт д.;ш новои версии кода, но обратное невоз- 
можно — усиление контракта отрицателг>но скажетсл на совместимости версии. 

В контрактах кода централг>ное место занимает статическии класс System. 
Diagnostics.Contracts.Contract: 

public static class Contract { 

// Методм c предусловимми : [Conditional("CONTRACTS_FULL")] 
public static void Requires(Boolean condition); 
public static void EndContractBlock(); 

// Предусловил: Always 

public static void Requires<TException>( 

Boolean condition) where TException : Exception; 

// Методм c постусловилми : [Conditional("CONTRACTS_FULL")] 
public static void Ensures(Boolean condition); 
public static void EnsuresOnThrow<TException>(Boolean condition) 
where TException : Exception; 

// СпециалБнме методм c постусловивми : Always 
public static T Result<T>(); 
public static T 01dValue<T>(T value); 
public static T ValueAtReturn<T>(out T value); 

// Инвариантнме методм обцекта: [Conditional("CONTRACTS_FULL")] 
public static void Invariant(Boolean condition); 

// Квантификаторние методу: Always 
public static Boolean Exists<T>( 

IEnumerable<T> collection, Predicate<T> predicate); 
public static Boolean Exists( 

Int32 fromlnclusive, Int32 toExclusivej Predicate<Int32> predicate); 
public static Boolean ForAll<T>( 

IEnumerable<T> collection, Predicate<T> predicate); 
public static Boolean ForAll( 

Int32 fromlnclusive, Int32 toExclusivej 
Predicate<Int32> predicate); 


1 Длл автоматического тестированил можно исполБзоватв инструмент Рех, созданнБ1и 
группои Microsoft Research: http://research.microsoft.com/en-us/projects/pex/. 
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// Вспомогателиние методн: 

// [Conditional ( "CONTRACTS_FULL" )] или [Conditional ( "DEBUG" )] 
public static void Assent(Boolean condition); 
public static void Assume(Boolean condition); 

// Инфраструктурное собнтие: обћ 1 чно в коде ато собнтие не исполвзуетсд 
public static event EventHandlen<ContnactFailedEventAngs> ContnactFailed; 

} 


Как упоминалосћ ранее, многим из зтих статических методов назначен атрибут 
[Conditional( "CONTRACTS_FULL" ) ] , а некотормм методам класса Helpen — еше 
и атрибут [Conditional( "DEBUG" ) ]. Зто означает, что при отсутствии специалБ- 
ного символа, определенного в момент компилнции, компилитор проигнорирует 
лгобои написаннми вами код вмзова зтих методов. Пометка Always означает, что 
компилнтор всегда будет создаватБ код вБ130ва зтих методов. Кроме того, методБ 1 
Requines, Requines<TException>, Ensunes, EnsunesOnThnow, Invaniant, Assent 
и Assume дополнителБно имегот перегруженнБШ версии (здесв они не показанБ1), 
принимагогцие аргумент типа Stning. В резулнтате вб1 можете в нвном виде задатв 
сообгцение, которое будет вбшодитбсн при нарушении контракта. 

По умолчаниго контрактБ 1 служат толбко длл документированин, и длн их вклгоче- 
нгот нужно вручнуго указатв в своиствах проекта символическое имн CONTRACTS_FULL. 
Также вам могут потребоватвсл дополнителБНБ1е инструментБ1 и панелБ своиств 
Visual Studio, которвго можно загрузитв с саита http://msdn.microsoft.com/en-us/ 
devlabs/dd491992.aspx. В пакет Visual Studio зти инструментБг покане входнт, так как 
нвлннсб относителБно Н 0 ВБ 1 МИ, они краине бкгстро развиваготсн. И на саите DevLabs 
новБге версии понвлнготсн бвгстрее, чем в обновленинх Visual Studio. После загрузки 
и установки новбгх инструментов понвитсл нован панелв своиств (рис. 20.9). 

Длл вклгоченгш контрактов кода установите флажок Perform Runtime Contract 
Checking и в расположенном справа от него раскрБшагогцемсл списке вкгберите 
вариант Full. Зто определлет символическое ими CONTRACTS_FULL при построении 
проекта и активизирует необходимвге инструментБг (они кратко описанБг далее) 
после его построенгш. В резулнтате нарушение контракта во времн ввшолненгш 
программБг будут сопровождатБСл собБгтием ContnactFailed класса Contnact. 
06 бшно разработчики не регистриругот методов с зтим собвгтием, но если bbi реши- 
те изменитв зтои традиции, все зарегистрированшле вами методБ1 получат обвект 
ContnactFailedEventAngs, которБп! вбшллдит следугогцим образом: 

public sealed class ContnactFailedEventArgs : EventArgs { 

public ContractFailedEventArgs(ContractFailureKind failureKind, 

String message, String condition, Exception originalException); 

public ContractFailureKind FailureKind { get; } 

public String Message { get; } 

public String Condition { get; } 

public Exception OriginalException { get; } 


public Boolean Handled { get; } // Верно, если хотб один обработчик 
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public void SetHandled(); 


// BbiBBan SetHhandled 

// Присваивает Handled значение truej 

// повволнл игнорироватв нарушение 


public Boolean Unwind { get; } 
public void SetUnwind(); 


// BepHOj если хоти один обработчик 
// вћввал SetUnwind или threw 
// Присваивает Unwind значение true, 

// принудителино генерирул ContractException 


} 
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Рис. 20.9. Панелн Code Contracts длн Visual Studio 


C зтим собмтием можно зарегистрироватБ множество методов его обработки. 
И каждћш такои метод может обработатк нарушение контракта указаннБш вами 
способом. Например, обработчик может записатв сведенгш о нарушении в журнал, 
проигнорироватБ нарушение (вБгзвав метод SetHandled) или завершитв процесс. 
При вБгзове лго6б1м из методов метода SetHandled нарушение считаетсл обрабо- 
таннвш и после резулитата, возврагценного методом обработки, приложение может 
работатв далБше, если, конечно, обработчик не вБгзвал метод SetUnwind. Если же 
такои вБгзов произошел, то после завершенин всех методов обработки генерируетсн 
исклгочение System.Diagnostics.Contnacts .ContractException. Зтовнутреннее 
исклгочение библиотеки MSCorLib.dll, значит, вбг не сможете написатБ блок catch длл 
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его перехвата. Если же какои-нибудБ из методов обработки становитсн источником 
необработанного исклточспин, сначала вБ13Бшак)тсл все осталБНБ1е обработчики, 
а затем генерируетсл исклгочение ContractException. 

Если обработчики со6бггии отсутствугот или ни один из них не вБ13Б1вает методБ 1 
SetHandled и SetUnwind и не становитсл источником необработанного исклгоче- 
нил, нарушение контракта сопровождаетсл заданнои по умолчаниго процедурои. 
Если среда CLR загружена, приложение оповегцаетсл о нарушении контракта. 
В случалх когда CLR запускает приложение в виде неинтерактивного оконного 
терминала (сгода относитсл, к примеру, Windows service application), вБ13Бшаетси 
метод Environment . FailFast, мгновенно завершагогции процесс. Если перед ком- 
пилнциеи 6 бш установлен флажок Assert On Contract Failure, понвитсл диалоговое 
окно, в котором с приложением можно будет свнзатв отладчик. При сброшенном 
флажке нарушение контракта сопровождаетсн исклгочением ContractException. 
Рассмотрим пример класса, исполвзугогции контрактБг кода. 

public sealed class Item {/*...*/} 

public sealed class ShoppingCart { 

private List<Item> m_cart = new List<Item>(); 
private Decimal m_totalCost = 0; 

public ShoppingCart() { 

} 

public void Addltem(ltem item) { 

AddItemHelper(m_cart, item, ref m_totalCost); 

} 

private static void AddItemHelper( 

List<Item> m_cart, Item newltem, ref Decimal totalCost) { 

// Предусловин: 

Contract.Requires(newltem != null); 

Contract.Requires(Contract.ForAll(m_cart, s => s != newltem)); 

// Постусловил: 

Contract.Ensures(Contract.Exists(m_cart, s => s == newltem)); 

Contract.Ensures(totalCost >= Contract.OldValue(totalCost)); 

Contract.EnsuresOnThrow<IOException>( 

totalCost == Contract.OldValue(totalCost)); 

// Какие-то операции (способние сгенерироватц I0Exception) 

m_cart.Add(newItem); 

totalCost += 1.00M; 

} 

// Инвариант 

[ContractlnvariantMethod] 
private void ObjectInvariant() { 
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Contract.Invariant(m_totalCost >= 0); 

} 

} 


В методе AddltemHelper определиетсн набор контрактов кода. Предусловие 
указшвает, что параметр newltem должен отличатБСл от null, а добавлиемБш 
в список злемент не может дублироватБ уже iiMeiomiicca. Постусловие гласит, 
что новбш олемепт должен присутствоватБ в списке, а обгцаи цена покупок после 
зтои операции должна увеличитвси. В постусловии также сказано, что если метод 
AddltemHelper по какои-то причине станет источником исклгоченин IOException, 
параметр totalCost должен сохранитв значение, которое он имел перед вбиовом 
метода. ЗакрвшБш метод Objectlnvariant гарантирует, что поле m_totalCost обв- 
екта не будет содержатк отрицателБного значенгш. 

ВНИМАНИЕ 

Все членБ1, на которне присутству10т ссбшки в предусловилх, постусловилх и инва- 
риантах, должнм 6biTb свободнБ! от сторонних зффектов. Такое требование свлзано 
с тем, что во времл тестированил ни в коем случае не должно менптБСч состолние 
обвекта. Кроме того, все методм, на которме есњ ссмлка в предусловии, должнм 
иметБ уровенБ доступа хотч 6bi не менђшии, чем у метода, определчкзидего само 
предусловие. В противном случае перед вмзовом метода не будет возможности 
проверитБСООтветствиеусловичм. Зто ограничение не касаетсп членов, на которме 
есљ ссмлки в постусловилх и инвариантах. Уровенв доступа к ним может бмљ лкзбмм; 
главное, чтобм код компилировалсч. Причина снчтич ограниченип состоит в том, что 
проверки в постусловии и инварианте не влил10т на корректносњ вмзова метода. 


ВНИМАНИЕ 

Что касаетсп наследованич, производнвш тип не может перегружањ и менчтв 
предусловил виртуалвнмх членов, определеннв1х в базовом типе. Аналогично, тип 
реализации члена интерфеиса не может менчњ предусловил, определеннме зтим 
членом. Если дпч члена отсутствует определеннвш в чвном виде контракт, значит, 
суидествует нечвнми контракт, которми логично представитв в таком виде: 

Contract . Requires(true) ; 

И так как при переходе к новои версии ужесточиљ контракт не получитсз (или придет- 
сл пожертвоватв совместимоствк) версии), при вводе новмх BnpTyaabHbix, абстракт- 
Hbix или интерфеиснмх членов следует очени аккуратно вмбираљ предусловил. Длч 
постусловии и инвариантов Bbi можете добавлчтБ и убирањ контрактв! пожеланииз, 
главное, чтобм услович, поставленнме в виртуалвном/абстрактном/интерфеисном 
члене, можно бмло логически соединитв с условипми в перегруженном члене. 


Итак, теперБ вбг знаете, как определцготсн контрактБт Пришло времи поговоритв 
о том, как они функциониругот во времи работвг программБт 06ђивлнтб предусло- 
вил и постусловин следует в верхнеи части методов, чтобвг их легко можно 6бшо 
наити. Предусловин провернготсн при ввгзове метода. При зтом хотелосв б r>i, чтобм 
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постусловин провернлисБ толбко после завершенин метода. Длн зтого созданнук) 
компилнтором C# сборку следует обработатБ инструментом Cocle Contract Rewriter 
(фаил CCRewrite.exe находитсл по адресу C:\Program Files (x86)\Microsoft\Contracts\ 
Bin) длн полученин ее модифицированнои версии. После установки флажка Perform 
Runtime Contract Checking Visual Studio начнет вмзмватБ зту утилиту автоматически 
егце на стадии создашш проекта. Утилита анализирует IL -код всех ваших методов 
и переписБгвает его таким образом, чтобкг постусловгш вбшолнчлисб толбко после за- 
вершешш методов. Длл методов, имегогцих несколвко точек вкгхода, утилита CCRewrite. 
ехе редактирует IL -код, заставлнл проверлтв условие перед завершением метода. 

Утилита CCRewrite.exe шцет в типеметодвг, помеченнБгеатрибутом [Contract- 
InvaniantMethod ]. Имн такого методаможет 6бгтб лго6бгм, но о6бшно его назБшагот 
Objectlnvaniant и добавлнгот модификатор pnivate (как н и сделал). Зтот метод 
не имеет аргументов и возврагцает void. Обнаружив его, CCRewrite.exe вставлиет 
IL -код ввгзова метода Ob jectlnvaniant после всех открвгтвгх зкземплнрнБгх методов. 
В резулвтате состонние обвекта провернетсн после возврагценгш значенгш каждвгм 
из методов, гараптируи, что ни один из них не нарушил условии контракта. Метод 
Finalize и метод Dispose класса IDisposable утилитои CCRewrite.exe не редак- 
тируготсл, потому что состоиние обвекта перед его уничтожением или отправкои 
в корзину не имеет никакого значенин. Следует также заметитв, что один тип может 
определнтБ несколБКО методов с атрибутом [ContnactlnvaniantMethod]; зто по- 
лезно при работе с частичнвгми типами. Утилита CCRewrite.exe перепишет IL -код 
таким образом, что все зти методвг будут вБгзБгватБСч (в неопределенном поридке) 
в конце каждого открвгтого метода. 

Методвг Assent и Assume не похожи на осталБннге. Во-первБгх, они не нвлнготсн 
частвго сгггнатурБг метода и их нелБЗн поместитБ в начало. Во времн вБгполненггч онгг 
деиствугот идентично: провернгот переданное ггм условие и в случае его несоблгоденгш 
генериругот исклгочение. Впрочем, еств егце и такои инструмент, как Code Contract 
Checker (CCCheck.exe), анализиругогции производимБш компилнтором C# IL -код в 
попвгтке статически удостоверитБСч в отсутствгггг нарушенгш контракта. Зта утилита 
пБгтаетсл удостоверитБСи, что все условин, переданнвге методу Assent, вБгполненБг. 
Если сделатБ зто не получаетсл, происходит переход к методу Assume. 

Рассмотрим пример. Допустим, имеетсл следугогцее определение типа: 

internal sealed class SomeType { 

private static String s_name = "Deffrey"; 

public static void ShowFirstLetter() { 

Console.WriteLine(s_name[0]); // внимание: требованин 

// не подтвержденм: index < this.Length 

} 

} 

При построении зтого кода с установленнБгм флажком Perform Static Contract 
Checking утилита CCCheck.exe вбгводит предупреждение, приведенное в коммен- 
тарии. Зто сообгцение уведомллет о том, что запрос первои букввг злемента s_name 
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может закончитБСн неудачеи и статћ источником исклгоченич, так как неизвестно, 
всегда ли s_name ссмлаетсч на строку, состоишук) хотл бм из одного символа. 
СледователБно, в метод ShowFinstLetten нужно добавитБ утверждение: 

public static void ShowFirstLetter() { 

Contract.Assert(s_name.Length >= 1); // внимание: утверждение 

// не подтверждено 

Consoie.WriteLine(s_name[0] ); 

} 

К сожалениго, анализирун зтот код, утилита CCCheck.exe все равно не может про- 
веритв, ссБшаетсл ли злемент s_name на строку, содержагцуго хотл 6ki один символ. 
В итоге мб1 снова получаем предупреждение. Иногда утилита не может проверитв 
утверждение из-за своих внутренних ограничении; веронтно, ее будугцие версии 
смогут осугцествлчтБ более полнбпг анализ. 

Что6б1 обоити недостатки зтои утилитБ1, переидем от метода Assent к методу 
Assume. Знаи наверннка, что никакои код не внесет изменении в злемент s_name, 
мб1 можем отредактироватБ метод ShowFinstLetten следугогцим образом: 

public static void ShowFirstLetter( ) { 

Contract.Assume(s_name.Length >= 1); // Предостережении нет! 
Console.WriteLine(s_name[0]); 

} 

B зтои версии кода утилита CCCheck.exe верит нам на слово и заклгочает, что 
злемент s_name всегда ссБшаетсл на строку, содержагцуго хотл 6 ki один символ. 
В резулвтате метод ShowFinstLetten проходит статическуго проверку контракта 
кода без предостерегаклцих сообшении. 

ОсталосБ рассмотретБ инструмент Code Contract Reference Assembly Generator 
(CCRefGen.exe). Утилита CCRewrite.exe ускорнет поиск ошибок, но произведеннБш 
в процессе проверки контракта код увеличивает размер вашеи сборки и отрица- 
телвно сказБ1ваетсл на производителБности. ИсправитБ зтот недостаток можно 
при помогци утилитБ 1 CCRefGen.exe, создагогцеи отделБнуго сборку со ссилкоп на 
контракт. В Visual Studio она запускаетсн автоматически, если ввгбратБ в раскрвг- 
ваготемси списке Contract Reference Assembly вариант Build. Сборки с контрактами 
обвшно носнт имн ИмлСборки. Contracts.dll (например, MSCorLib.Contracts.dll) и со- 
держат толбко метаданнкге и описБшагогции контракт IL -код. ОпознатБ их можно 
также по примененному к таблице метаданнБгх с определением сборки атрибуту 
System.Diagnostics.Contnacts.ContnactRefenenceAssemblyAttnibute. Утилитбг 
CCRewrite.exe и CCCheck.exe могут исполБЗОватБ сборки со сскшками на контракткг 
в качестве входнбгх ддннбгх дли анализа. 

Ну и самБш последнии инструмент Code Contract Document Generator (CCDocGen. 
ехе) добавлнет информациго о контракте в ХМВ-фаил, создаваемБп! компилнтором 
C# при установке переклгочателн /doc : f ile. Зтот ХМВ-фаил, дополненнвш утили- 
Toii CCDocGen.exe, после обработки инструментом Sandcastle вкгдает документациго 
в стиле MSDN с информациеи о контрактах. 



Глава 21. Автоматическое 
управление памвтБК) 
(уборка мусора) 


В зтои главе рассказано о создании новмх обвектов управлиеммми приложенинми, 
о том, как управлиеман куча распорнжаетсл временем жизни отих обвектов и как 
освобождаетсл занитаи ими памнтБ. Мм рассмотрим работу уборгцика мусора 
обгцензмковои средм CLR и проблемм, свизаннме с его производителмностмо. 
В конце главм речБ поидет о приемах проектированин приложении, зффективно 
исполБзугогцих памнтБ. 


Управллемал куча 

Лгобал программа исполнзует ресурсБг — фаилБ 1 , буферБг в памити, пространство 
зкрана, сетеввге подклгоченин, базБ 1 даннБгх и т. п. В обБектно-ориентированнои 
среде каждвги тип идентифицирует некии доступнкпг зтои программе ресурс. Что6бг 
им восполБЗОватБСн, должна 6 бгтб вБгделена памитн длл представленгш зтого типа. 
Дли доступа к ресурсу вам нужно: 

1. ВвгделитБ памнтБ длл типа, представлигогцего ресурс (обвгчно зто делаетси при 
помогци оператора new в С#). 

2. ИнициализироватБ вБгделеннуго памнтн, установив началвное состонние ресурса 
и сделав его пригоднвш к исполБЗОваниго. За установку началвного состоннгш 
типа отвечает его конструктор. 

3. ИсполвзоватБ ресурс, обрагцансБ к членам его типа (при необходимости опера- 
цгш может повторитБСи). 

4. В рамках процедурБг очистки уничтожитк состочние ресурса. 

5. ОсвободитБ памитБ. За зтот зтап отвечает исклгочителвно уборгцик мусора. 

Зта простан на первБги взглид парадигма стала одним из основнбгх источни- 
ков ошибок у программистов, которвш приходитсл вручнуго управлнтв памнтБго, 
а именно программистов С++. Программиствг, ответственнБге за управление памн- 
тбго, хронически забнгвагот освободитв памитБ, ставшуго ненужнои, гглгг пвгтаготси 
ггсполБЗОватБ уже освобожденнуго памитв. Пргг неуправлиемом программировании 
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зти два вида ошибок в приложенинх опаснее осталБнмх, так как обмчно нелБЗп 
предсказатБ ни их последствии, ни периодичностБ их поивленин. Прочие ошибки 
доволбно просто исправитБ, заметив, что приложение функционирует неправилБно. 

Если вб1 пишете код, безопаснБп! по отношеншо к типам (без ислолБЗОвашш клго- 
чевого слова C# unsafe), повреждение памлти в ваших приложенгшх невозможно. 
Утечки памлти остаготсн теоретически возможнбши, но они не происходлт в стан- 
дартнои ситуации. Как правило, утечки памнти возникагот из-за того, что приложение 
хранит обвектБ1 в коллекции, но не удаллет их, когда они становитсп ненужнвши. 

Ситуацин дополнителБно упрогцаетсл тем, что дли болБшинства типов, регу- 
лирно исполвзуемБ1х разработчиками, шаг 4 (уничтожение состопнгш ресурса) не 
пвлнетсл обнзателБНБш. Таким образом, управлнемаи куча, кроме ликвидации уже 
упомннутмх ошибок, также предоставлнет разработчику простуго моделв програм- 
мировангш: программа вБвделнет и инициализирует ресурс, после чего исполБзует 
его так долго, сколбко понадобитси. Длн болкшинства типов очистка ресурсов не 
нужна, памнтБ просто освобождаетсл уборгциком мусора. 

При исполБзовании зкземплиров типов, требугогцих специалБнои очистки, 
моделБ программировангш остаетсл такои же простои. Впрочем, иногда очистка 
ресурса должна вбшолннтбсн как можно ранкше, не дожидансБ вмешателБСтва убор- 
гцика мусора. В таких классах можно ввгзватБ дополнителБНБги метод (назБшаемБш 
Dispose), что6бг очистка бкша вБшолнена по вашему собственному расписаниго. 
С другои сторонБг, реализацгш типа, требугогцего с.пециалБнои очистки, нвлиетси 
нетривиалБнои задачеи. Подробности будут изложенБг позднее в зтои главе. Как 
правило, типбг, требугогцие специалБнои очистки, исполБзугот низкоуровневБге 
системнБге ресурсБг — фаилБГ, сокетБг гглгг подклгоченггн к базе даннкгх. 

Вмделение ресурсов из управллемои кучи 

В CLR памнтБ дли всех ресурсов ввгделлетсл ггз так назБгваемои управлмемоп кучи 
(managed heap). Пргг ггнггцггализацгггг процесса CLR резервггрует областв адрес- 
ного пространства под управлиемуго кучу, а также указателв, которБш н назБгваго 
NextObjPtr. Он определлет, где в куче будет ввгделена памнтБ длл следугогцего 
обвекта, гг ггзначалБно указБгвает на базоввги адрес зтои зарезервггрованнои областгг 
адресного пространства. 

По мере заполненггп области обвектами CLR ввгделиет новБге области, вплотб 
до заполненггп всего адресного пространства. Такггм образом, памнтв прггложенггн 
огранггчггваетсл вггртуалБНБгм адреснБгм пространством процесса. Длн 32-разрнднБгх 
процессов можно ввгделитБ до 1,5 гигабаита памити, а дли 64-разриднБгх процес- 
сов — около 8 терабаит памитгг. 

Пргг вБгполненгггг оператора C# new среда CLR: 

1) подсчитБгвает колггчество баитов, необходимвгх длл размегценггп полеи тггпа 
(гг всех полеи, унаследованнвгх от базового типа); 

2) прггбавлнет к полученному значенггго колггчество баитов, необходимвгх длн раз- 
мегценггп системнБгх полеи обвекта. У каждого обвекта естк пара такггх полеи: 
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указателБ на обЂект-тип и индекс блока синхронизации. В 32-разрмдп1>1х при- 
ложенинх дли каждого из зтих полеи требуетси 32 бита, что увеличивает размер 
каждого обвекта на 8 баит, а в 64-разрнднБ1х приложенилх каждое поле занимает 
64 бита, добавлии к каждому обвекту 16 баит; 

3) провернет, хватает ли в зарезервированнои области баитов на вБвделение па- 
мити дли обвекта (при необходимости передает памнтБ). Если в управлиемои 
куче достаточно места длл обвекта, ему вБвделнетси памитБ, начинаи с адреса, 
на которБпт ссБшаетси указателБ NextObjPtn, а занимаемБШ им баитБ1 обнули- 
кј гсч. Затем вБИБшаетсн конструктор типа (передагогции NextObjPtr в качестве 
параметра this), и оператор new возврашдет ссвшку наобвект. Перед возвратом 
зтого адреса NextOb ј Ptn переходит на перввш адрес после обвекта, указБшач на 
адрес, по которому в куче будет помегцен следугогции обЂект. 

На рис. 21.1 изображена управлиемаи куча с тремн обвектами: А, В и С. Новбпт 
обвект размешаетсл по адресу, заданному указателем NextObjPtn (сразу после 
обвекта С). 


А 

В 

С 





N extO bj Ptr 


Рис. 21.1. Толбко что инициализированнал управллемал куча с тремн обвектами 

Длн управлнемои кучи вБвделение памнти длл обвекта сводитсн к простому 
увеличениго указатели — зта операцин вБшолнчетси почти мгновенно. Во многих 
приложениих обБектБц вБвделлемБге примерно в одно времн, тесно свизанБ1 друг с 
другом, к тому же часто к ним обрагцаготсн примерно в одно времч. Так, обвшно сразу 
после обвекта FileStneam создаетсл обвект BinanyWniten. Затем приложение об- 
рагцаетсн кобвекту BinanyWniten, внутреннии код которого исполвзует FileStneam. 
В среде, поддерживагогцеи уборку мусора, новвге обЂектвг располагаготсн в памити 
непрервшно, что повБшгает производителБностБ за счет близкого расположенгш 
ссбшок. В частности, зто значит, что рабочии набор процесса будет менкше, чем у 
подобного приложенгш, работагогцего в неуправлиемои среде. Также, скорее всего, 
все обБектБг, исполБзуемБге в программе, уместлтсл в кзше процессора. Прило- 
жение сможет получатв доступ к зтим обвектам с феноменалБнои скоростБго, так 
как процессор будет вбшолннтб 6олбшинство своих операции без кзш-промахов, 
замедлигогцих доступ к оперативнои памити. 

Итак, пока складвгваетси впечатление, что управлнемаи куча обладает превос- 
ходнбгми характеристиками бБгетродеиствгш. И все же зто описание предполагает, 
что памнтБ всегда бесконечна, а CLR всегда может вввделитБ блок дли нового обвекта. 
Конечно, зто не так, позтому управлиемои куче необходим механизм уничтоженгш 
обЂектов, которвге перестали 6бгтб нужнБгми приложениго. Таким механизмом 
ивлнетсл уборка мусора (Garbage Collection, GC). 
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Алгоритм уборки мусора 

Когда приложение вмзмвает оператор new дли созданин обвекта, оставшегосн адрес- 
ного пространства может не хватитБ длн вБвделенип памити под обвект. В таком 
случае CLR вБгполнпет уборку мусора. 

ВНИМАНИЕ 

Зто весБма упрош,енное описание работм уборш,ика мусора. В деиствителБности 
уборка мусора вмполнлетсл при заполнении поколенил 0. Подробнее о поколенилх 
Mbi поговорим чутБ позже, а пока длл простотм будем считати, что уборка мусора 
происходит при заполнении кучи. 


Длл управленгш сроком жизни обвектов в некоторвгх системах исполвзуетсл 
алгоритм подсчета ссбглок. Например, он исполБзуетсл в модели Microsoft СОМ 
(Component Object Model). В системах с подсчетом ссбглок каждкги обвект в куче 
содержит внутреннее поле с информациеи о том, сколбко <<частеи» программкг в на- 
стоигцее времи исполвзугот даннБги обвект. Когда каждал «частк» переходит к точке 
кода, в которои обвект становитсл недоступнвгм, она уменБгпает поле счетчика 
обвекта. Когда значение счетчика уменБшаетсн до 0, обвект удаллетси из памити. 
К сожалениго, в системах с подсчетом ссбглок возникагот сервезнБге проблемБг 
с циклическими ссБглками. Например, в графическом приложении окно содержит 
ссвглку на дочернии злемент полБЗОвателБСКого интерфеиса, а дочернии злемент 
полБЗОвателБСКого интерфеиса содержит сскглку на свое родителвское окно. Зти 
ссбглки не позволнгот счетчикам двух обвектов уменБшитвси до 0, позтому оба обв- 
екта остаготсн в памнти даже тогда, когда окно перестало 6бгтб нужнБгм приложениго. 

Из-за проблем с алгоритмами, основаннБгми на подсчете ссбглок, CLR вместо 
зтого исполБзует алгоритм отслеживанил ссилок. Алгоритм отслеживантш ссбглок 
работает толбко с переменнБгми ссбглочного типа, потому что толбко зти переменнБге 
могут ссБглатБСи на обвектБг в куче; переменнвте значимБгх типов просто содержат 
даннБге зкземшшра значимого типа. СсБтлочнБте переменнБге могут исполБЗОватБ- 
си во многих контекстах: статические и зкземплирнвге по.ти классов, аргументвг 
методов, локалБНБге переменнБте. Все переменнБге ссбглочнбгх типов назвгваготсл 
корнлми (roots). 

Когда среда CLR запускает уборку мусора, она сначала приостанавливает все 
программнБге потоки в процессе. Тем самвтм предотврагцаетсл обрагцение к обвектам 
и возможное изменение состоннтш во времи их анализа CLR. Затем CLR перехо- 
дит к зтапу уборки мусора, назвтваемому маркировкоп (marking). CLR перебирает 
все обвектБг в куче, задаван биту в поле индекса блока синхронизации значение 0. 
Зто означает, что все зти обвектБг могут 6бттб удаленБг. Затем CLR провериет все 
активнБге корнгг и обвектБг, на которнге онгг ссБглаготсн. Если коренБ содержит null, 
CLR игнорирует его и переходит к следугогцему корнго. 

Если коренБ ссБглаетси на обвект, в поле индекса блока синхронизации устанав- 
ливаетси бит — зто и еств признак маркировки обвекта. После маркировки обвекта 
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CLR провернет все корни в зтом обвекте и маркирует обвектм, на которме они 
ссмлаготси. Встретив уже маркированнми обвект, уборндик мусора останавливаетси, 
чтобм и.збежатР) возникновентш бесконечного цикла в случае циклических ссмлок. 

На рис. 21.2 показана куча с песко ижими обвектами, в которои корни прило- 
женин напрнмуго ссмлаготсн на обвектм А, С, D и F. Все зт и обвектм маркируготсн. 
При маркировке обвекта D уборгцик мусора обнаруживает, что в зтом обвекте естБ 
поле, ссмлагогцееси на обтект Н, позтому обвект Н также помечаетсн. Затем уборгцик 
продолжает рекурсивнми просмотр всех достижиммх обвектов. 



Рис. 21.2. Управллемал куча до уборки мусора 

После проверки всех корнеи куча содержит набор маркированнмх и немаркиро- 
ваннмх обвектов. Маркированнме обвектм переживут уборку мусора, потому что 
на них ссмлаетси хотл бм один обвект; можно сказатБ, что они достижимбг из кода 
приложенгш. НемаркированнБге обвектБг недостижимБг, потому что в приложении 
не сугцествует корнн, через которвпг приложение могло 6бг к ним обратитБСи. 

ТеперБ, когда CLR знает, какие обвектБг должнбг остдтбси, а какие можно уда- 
литб, начинаетсн следугогцан фаза уборкгг мусора, назкгваеман сжатием (compacting 
phase). В зтогг фазе CLR перемегцает внггз все <<немусорнвге» обвектБг, что6бг 
онгг занггмалгг смежнБш блок памнтгг. Перемегценгге ггмеет много преггмугцеств. 
Во-перввгх, оставшггесн обвектБг будут находггтБСн поблггзостгг друг от друга; зто 
приводит к сокрагценггго размера рабочего набора приложенггн, а следователвно, 
повБгшает производггтелБностБ обрагценггн к зтггм обвектам в будугцем. Во-вторвгх, 
свободное пространство тоже становггтси непрервгвнБгм, что позволнет освободитв 
зту областБ адресного пространства. Наконец, сжатгге позволнет избежатв проблем 
фрагментацгггг адресного пространства пргг ггсполБЗОвангггг управлиемогг кучгг. 

После перемегценгш в памити все ссбглкгг на <<вБгжггвшгге» обвектБг из корнеи 
указБгвагот на прежнее местонахожденгге обвекта в памитгг, а не на тот адрес, по 
которому обвект 6бгл перемегцен. Если возобновитБ вБгполненгге потоков на зтои 
стадигг, потокгг обратитсн по старвгм адресам, что прггведет к некорректному ггс- 
полБЗОванггго памнтгг. Разумеетсл, зтого допускатв нелБЗи, по.зтому в фазе сжатии 
CLR ввгчитает из каждого корнн колггчество баит, на которое обвект 6бгл сдвинут 
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вниз в памнти. Тем саммм гарантируетсн, что каждми коренБ будет ссмлатћсн на тот 
же обвект, что и прежде; просто сеичас зтот обвект оказалсн в другом месте памнти. 

После сжатил памити кучи в указателБ NextOb ј Ptn управлиемои кучи заноситсн 
первми адрес за последним обвектом, не нвлпгогцимси мусором. По зтому адресу 
следугогции новми обвект будет размегцен в памнти. На рис. 21.3 показана управ- 
лнеман куча после сжатии. После завершенгш фазм сжатин CLR возобновлнет вм- 
полнение потоков приложенгш, а они обрагцаготсн к обвектам так, словно никакои 
уборки мусора и не бмло. 
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Рис. 21.3. Управлаемаа куча после уборки мусора 


Если CLR не удаетсл освободитг. памнтБ в резулвтате уборки мусора, а в про- 
цессах не осталосв адресного пространства длн ввгделенгш нового сегмента, значит, 
свободнал памлтв процесса полностбго исчерпана. В зтом случае попБ 1 тка вБвделенгш 
новои памити оператором new приведен к ввгдаче исклгоченгш OutOfMemoryExcep- 
tion. Ваше приложение может перехватитБ зто исклгочение и восстановитБСн после 
него, но болБшинство приложении не пБпаегси зто делатв; вместо зтого исклгочение 
преврагцаетси в необработанное, Windows завершает процесс, а затем освобождает 
всго памнтв, исполБЗОваннуго процессом. 

Программист должен извлечв длл себи несколБКО важнкгх уроков из зтого опи- 
сангш. Во-первБгх, исклгочаетси утечка обвектов, так как все обБектБц недоступнБШ 
от корнеи приложенгш, рано или поздно уничтожает уборгцик мусора. Во-вторБ 1 х, 
благодарн уборке мусора невозможно получитв доступ к освобожденному обвекту 
с последугогцим повреждением памнти. 

ВНИМАНИЕ 

Статическое поле типа хранит обвект, на которбш сснлаетса, бессрочно или до 
вмгрузки домена приложении с загруженнБ 1 ми типами. Чагде всего утечка памлти 
возникает из-за храненил в статическом поле ссбшки на коллекцик), в которукз 
добавллизтсл злементБг Статическое поле сохранлет обнект коллекции, которал, 
в свокз очередБ, сохранлет все свои злементБ!. Поатому статических полеи следует 
по возможности избегатБ. 
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Уборка мусора и отладка 

Как толбко oo'bc кт становитсл недостижиммм, он преврашаетсл в кандидата на 
удаление — обвектм далеко не всегда <<доживак>т» до завершенин работм метода. 
Длн приложенин зта особенностБ может иметБ интереснБге последствин. Например, 
рассмотрим следуклции код: 

using System; 

using System.Threading; 

public static class Program { 
public static void Main() { 

// Создание обБекта Timer, вћвнванлцего метод TimerCallback 
// каждме 2000 миллисекунд 

Timer t = new Timer(TimerCallback, null, 0 , 2000); 

// Ждем, когда полвзователв нажмет Enter 
Console.ReadLine() ; 

} 

private static void TimerCallback(Object o) { 

// Вмвод датн/времени внзова зтого метода 
Console.WriteLine("In TimerCallback: " + DateTime.Now); 

// ПринудителБнми вћвов уборцика мусора в зтои программе 
GC.Collect(); 

} 

} 


Откомпилируите зтот код из команднои строки, не исполБзун никаких специ- 
алБНБ1х параметров компилнтора. Затем, запустив полученнвш исполннемБпт фаил, 
вб1 увидите, что метод TimerCallback вБ13Бшаетсл всего один раз! 

После изученил приведенного кода складвшаетсл впечатление, что метод 
TimerCallback будет вБ13БшатБСи каждБге 2000 миллисекунд. В конце концов, mbi 
создаем обвект Т imer, на которвш ссвшаетсл переменнан t. Посколвку таимер сугце- 
ствует, он долженсрабатвшатБ. Но обратите внимание, что в методе Т imerCallback 
процедурауборкимусора 1 : 1 . 131,1 настсм принудителБнометодом GC.Collect(). 

После запуска уборгцик мусора предполагает, что все о6б6ктб1 в куче недостижи- 
мб1 (то естБ НВЛИ10ТСН мусором), в том числе обвект Timer. Затем уборгцик провернет 
корни приложенил и видит, что метод Main не исполвзует переменнуго t после 
присвоенин eii значешш. Позтому в приложении нет переменнои, ссвшагогцеисн на 
обвект Timer, и уборгцик мусора освобождает занитуго им памнтв. В итоге таимер 
останавливаетси, а метод TimerCallback ввгоБшаетсл всего один раз. 

Допустим, вб1 исполБзуете отладчик длл метода Main, а уборка мусора происходит 
сразу после присвоешш переменнои t адреса нового обвекта Т imer. Что случитсл, 
если затем bbi попБ1таетесв просмотретБ обвект, на которБ1и ссишаетсл t, в окне 
Quick Watch отладчика? Отладчик не сможет показатв обвект, потому что тот 6бш 
удален уборгциком мусора. Дли многих разработчиков такои вариант развитил 
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собмтии стал бм очеш. непринтнмм сторпризом, позтому специалистм Microsoft 
предложили другое решение. 

При компилнции сборки с клгочом /debug компилнтора C# компилнтор при- 
меннет к полученнои сборке атрибут System.Diagnostics .DebuggableAttnibute 
с установленнБш флагом DisableOptimizations. При компилиции метода во 
времн вмполненгш JIT -компилнтор видит, что зтот атрибут задан, и искусственно 
продлевает времи жизни всех корнеи до завершенгш метода. В моем примере JIT- 
компилнтор считает, что переменнан t в Main должна сугцествоватБ до конца метода. 
Таким образом, если происходит уборка мусора, уборгцик теперг. считает, что t 
остаетсч корнем, а обвект Т imen, на которми ссмлаетсл t, по-прежнему достижим. 
Обвект Timen переживет уборку мусора, а метод TimenCallback будет вмзмватмш 
многократно вплотб до ш.гхода из Main. 

Что 6 б 1 убедитБСл в зтом, перекомпилируите программу из команднои строки, 
но на зтот раз укажите клгоч компилитора C# /debug. Теперв при ввгполнении 
полученного исполннемого фаила метод TimenCallback будет вБ13Б1ватБСн много- 
кратно! Учтите, что клгоч /optimize+ компилнтора C# снова вклгочает оптимизации, 
позтому он не должен исполвзоватБСн при проведенгш зксперимента. 

JIT -компилитор делает зто, чтобвг помочб вам в процессе отладки. Теперв мож- 
но запуститв приложение в обвшном режиме (без отладчика), и если метод будет 
вБгзван, JIT -компилитор искусственно увеличит времн жизни переменнвгх до его 
окончангш. Затем, если к процессу будет добавлен отладчик, можно вставитв точку 
останова в ранее скомпилированнБш метод и изучитБ переменнБге. 

ТеперБ вб1 знаете, как создатк программу, которач работает в отладочном вари- 
анте, но не работает должнбгм образом в готовои версии. Но программа, корректно 
работагогцан толбко в режиме отладки, бесполезна. Позтому необходимо средство, 
обеспечивагогцее работу программвг независимо от типа ее сборки. 

Можно попробоватв изменитБ метод Main следугогцим образом: 

public static void Main() { 

// Создание обБекта Timen, вмзмвакицего метод TimerCallback каждме 2000 мс 
Timer t = new Timer(TimerCallback, null, 0, 2000); 

// Ждем, когда полвзователБ нажмет Enter 
Console . ReadLine( ) ; 

// Создаем ссмлку на t после ReadLine 

// (в ходе оптимизации зта строка удалнетсл) 

t = null; 

} 

Все равно после компиллции зтого кода (без параметра /debug+) и запуска полу- 
ченного исполннемого фаила (без отладчика) вбшснитсн, что метод Timen_Callback 
вБгзБгваетси всего раз. Дело здесв в том, что JIT -компшштор пвлнетсл оптимизиру- 
гогцим, а приравнивание локалвнои переменнои или переменнои-параметра к null 
равнозначно отсутствиго ссбглки на зту переменнуго. Иначе говорн, Ј1Т-компилнтор 
в ходе оптимизации полностбго убирает строку t = null; из программкг, из-за 
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зтого она работает не так, как хотелосћ 6\л. Вот как правилБно следовало изменитБ 
метод Main: 

public static void Main() { 

// Создание обБекта Timer, вмзмвакпцего метод TimerCallback каждме 2000 мс 
Timer t = new Timer(TimerCallback, null, 0, 2000); 

// Ждем, когда полвзователБ нажмет Enter 
Console.ReadLine(); 

// Создаем ссмлку на переменнукз t после ReadLine 
// (t не удалнетсл уборшиком мусора 
// до возвратенип управленил методом Dispose) 
t.Dispose(); 

} 

ТеперБ, скомпилировав зтот код (без параметра /debug+) и запустив полученнБп) 
исполннемБш фаил (без отладчика), bki увидите, что метод TimerCallback ВБ 13 Б 1 - 
ваетсн несколвко раз, и программа работает корректно. Зто обБисннетсл тем, что 
оођокт, на KOTopniii ссБ1лаетсч переменнан t, не должен удаллтБСи, что6б1 длн него 
можно 6бшо вБИватБ метод Dispose (значение t нужно передатн методу Dispose 
как аргумент this). Парадокс: нвно указвшан, в каком месте таимер должен 6bitb 
уничтожен, mhi продлеваем его жизнб до зтои точки. 

ПРИМЕЧАНИЕ 

После всего сказанного не стоит преждевременно беспокоитБса о том, что ваши 
собственнме обЂектм могут 6мтб уничтоженм ранБше времени. Класс Timer ис- 
полБЗОвалсл в обсуждении толбко из-за своего специфического отсутствукидего 
у других классов поведенич. Дело в том, что присутствие в куче обвекта Timer при- 
водит к периодическому вмзову метода. Другие типм не в состопнии так себч вести. 
К примеру, наличие в пампти обвекта String не имеет никаких последствии. Строка 
просто находитсл в куче. Именно позтому, чтоби продемонстрироватБ, как работакгг 
корни и каквремч жизни обвекта свлзано с отладчиком, ч исполБЗОвал обнектТЈтег. 
Но при зтом основнои вопрос состолл не в том, как растлнутБ времл жизни обнекта. 
Времп жизни осталБНБ 1 х обнектов определлетсл приложением автоматически. 


Поколенил 

Уборцик мусора с поддержкоп поколенип (generational garbage collector), KOTopniii 
также назмвагот зфемерним уборгциком мусора (ephemeral garbage collector), хоти 
н не исполБзуго такои термин в своеи книге, работает на основе следукнцих пред- 
положении: 

□ чем младше обвект, тем короче его времн жизни; 

□ чем старше обвект, тем длиннее его времн жизни; 

□ уборка мусора в части кучи ввшолшгетсл бмстрсс, чем во Bceii куче. 
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СправедливостБ зтих предположении длн болћшого набора сугцествукнцих при- 
ложении доказана многочисленнБши исследованиими, позтому они повлгшли на 
реализацшо уборгцика мусора. В отом разделе описан принцип работћг поколении. 

Сразу после инициализации в управлнемои куче нет обвектов. Говорнт, что 
создаваемвге в куче обвектБг составлнгот поколение 0. Прогце говорн, к нулевому 
поколениго относнтсн толбко что созданнБге обвектБг, которБгх не касалсн уборгцик 
мусора. Рисунок 21.4 демонстрирует толбко что запугценное приложение, раз- 
местившее в памнти пнтб обвектов ( А—Е ). Через некоторое времи обвектБг С и Е 
становнтсл недоступнвгми. 


1 ^ 1 

1 т 1 

с 

D 

Е 
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Поколение 0 


Рис. 21.4. Вид кучи сразу после инициализации: все обвек™ в неи относлтсл 
к поколенико 0, уборка мусора еш,е не вБтолнлласБ 

Пргг ггнициализации CLR вБгбирает пороговБги размер длн поколенггп 0. Если 
в резулкгате вБгделенгш памлтгг длл нового обвекта размер поколенгш 0 преввгшает по- 
роговое значенгге, должна начатвсн уборка мусора. Д опустим, обвектБг А -Е относлтсн 
к поколенггго 0. Тогда пргг размегценгггг обвекта Едолжна начатБСи уборка мусора. 

Уборгцггк мусора определиет, что обвектБг С и Е — зто мусор, гг вБгполниет сжатгге 
памнти длн обвекта D, перемегцан его вплотнуго к обвекту В. ОбвектБг, пережившие 
уборку мусора (А, В и D), становнтси поколением 1. ОбвектБг из поколенин 1 6бгли 
проверенБг уборгциком мусора одггн раз. ТеперБ куча вбггллдит так, как показано 
на рис. 21.5. 
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Рис. 21.5. Вид кучи после однои уборки мусора: вБ 1 жившие обвек™ из поколенил 0 
переходлт в поколение 1, поколение 0 пустует 

После уборки мусора обвектов в поколенигг 0 не остаетси. Туда помегцаготсн но- 
ввге обвектБг. Как показано на рггс. 21.6, приложенгге продолжает работу гг размегцает 
обвектБг F—K. Также в ходе работвг приложенгш становнтсн недоступнвши обвектБг 
В, Н и Ј, позтому заннтаи ими памнтн должна рано или поздно освободггтБСн. 


А 

В 

D 

F 

G 

Н 

1 

Ј 

К 


— 

-► 


Поколение 1 ПоколениеО 

Рис. 21.6. В поколении 0 полвилисб новме обБектм, в поколении 1 — мусор 
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А теперћ представкге, что при попмтке размешенин обвекта L размер поколенин 0 
превмсил пороговое значение, позтому должна начатБСч уборка мусора. При зтом 
уборгцик мусора решает, какие поколенин следует обработатБ. И уже упоминал, 
что при инициализации CLR вмбирает пороговми размер поколенгш 0; CLR также 
вмбирает пороговми размер длл поколенгш 1. 

Начинан уборку мусора, уборгцик определиет, ско. п.ко памлти заннто поколе- 
нием 1. Пока поколение 1 занимает намного меш.ше отведеннои памлти, позтому 
уборгцик провериет толбко обвектм поколенин 0. Егце раз просмотрите предполо- 
женгш, на котормх базируетси работа уборгцика мусора. Первое допугцение гласит, 
что у новмх обвектов времи жизни короче. Позтому в поколении 0, скорее всего, 
окажстси много мусора, и очистка зтого поколении освободит много памити. А по- 
сколБку уборгцик игнорирует обвектм поколенин 1, уборка мусора значителг>но 
ускорнетси. 

Псно, что игнорирование обвектов поколенип 1 повмшает бмстродеиствие убор- 
гцика. Однако его производителг>ностг. растет егце бо./п.шс благодарн вмборочнои 
проверкгг обвектов в управлнемои куче. Если коренБ гглгг обт.ект ссмлаетсп на обг.ект 
из старшего поколенин, уборгцик игнорирует все внутренние ссмлки старшего обв- 
екта, сокрагцаи времч построенин графа доступнмх обвектов. Конечно, возможна 
ситуацин, когда старми обг.ект ссмлаетсл на новми. Чтобм не пропуститБ обнов- 
леннме полн зтих стармх обЂектов, уборгцик исполвзует внутреннии механизм 
JIT -компилнтора, устанавлггвагогцгги флаг при изменении ссмлочного по.гм обЂекта. 
Он позволнет уборгцику вђгнснитђ, какие из стармх обЂектов (если они еств) бмли 
измененм с момента последнеи уборки мусора. Остаетсн проверитв толђко старме 
обЂектм с измененнмми полнми, чтобм вђгиснитђ, не ссмлаготсн ли они на новме 
обг,окгт ,1 из поколенин 0 1 . 

ПРИМЕЧАНИЕ 

TecTbi бв1Стродеиствиз, проведенне1е Microsoft, показали, что уборка мусора в по- 
колении 0 занимает менише 1 мс. Microsoft стремитсл ктому, чтобн уборка мусора 
занимала не болише времени, чем обслуживание обвннои страничнои ошибки. 


1 Когда ЈГГ-компилнтор создает машиннми код, модифициругогции ссмлочное поле внутри 
обвекта, туда входит внзов барг>ерного метода записи (write barrier method). Зтот метод про- 
вернет, принадлежит ли обвект, полн которого изменнготсл, к поколеншо 1 или 2. В случае 
положителшого резулшата код барг>ерного метода записи устанавливает бит во внутреннеи 
таблице (card table). Зта таблица содержит по одному биту длн каждого 128-баитного диа- 
пазона данннх в куче. В начале следугогцего цикла сборки мусора из таблицн определлетсл, 
полн каких обвектов поколении 1 и 2 изменилисБ с момента прошедшеи сборки. Если какои-то 
из зтих обвектов сснлаетсл на обвект поколенил 0, зтот обг>ект переживает уборку мусора. 
После завершенгш процедурн всем полнм таблггцвг возврагцаготсн нулевне значенин. Наличие 
кода барг>ерного метода записи негативно сказБгваетсл на производителћности при записи 
сснлочннх полеи у обвекта (в отличие от локалвннх переменннх или статических полеи). 
ПроизводителБностБ падает егце болБше, если обвект принадлежит поколениго 1 или 2. 
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Уборшик мусора с поддержкои поколении также предполагает, что обЂектш, 
прожившие достаточно долго, продолжат житб и далБше. Так что велика веронт- 
ностБ, что обЂектм поколенип 1 и впредЂ останутсл доступншми в приложении. 
То еств проверив обЂектм поколенгш 1, уборгцик нашел бм мало мусора и не смог 
бм освободитЂ много памнти. СледователЂно, уборка мусора в поколении 1, скорее 
всего, окажетси пустои тратои времени. Если в поколении 1 понвлиетси мусор, он 
просто остаетсл там. Сеичас куча вмглндит, как показано на рис. 21.7. 
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Рис. 21.7. Вид кучи после двух операции уборки мусора: вмжившие обвек™ 
из поколенил 0 переходлт в поколение 1 (увеличивал его размер), 
поколение 0 пустует 

Как видите, все обЂектш из поколенин 0, пережившие уборку мусора, перешли 
в поколение 1. Так как уборгцик не провериет поколение 1, памитв, занитаи обЂек- 
том В, не освобождаетсл, даже если зтот обвект на момент уборки мусора недоступен. 
И в зтот раз после уборки мусора поколение 0 пустеет, в зто поколение попадут 
новме обЂектм. Допустим, приложение работает далнше и вмделиет памнтв под 
обЂектм L-O. Во времн работм приложение прекрагцает исполвзоватЂ обЂектм G, 
L и М, и они становитсн недоступнмми. В резулвтате куча вмглидит так, как по- 
казано на рис. 21.8. 


А 

В 

D 

F 

G 

1 

К 

L 

М 

N 

0 


- 1 

-► 


Поколение 1 ПоколениеО 

Рис. 21.8. В поколении 0 созданн новме обЂектм, количество мусора 
в поколении 1 увеличилосв 

Допустим, в резулвтате размегценгш обЂекта Р размер поколенгш 0 превмсил 
пороговое значение, что иницгшровало уборку мусора. Посколвку все обЂектм 
поколенгш 1 занимагот в совокупности менвше порогового уровни, уборгцик вновђ 
решает собратЂ мусор толђко в поколении 0, игнорирун недоступнме обЂектм в по- 
колении 1 ( В и G). Куча после уборки мусора показана на рис. 21.9. 
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Рис. 21.9. Вид кучи после трех операции уборки мусора: вн> 1 жившие обвектн 
из поколенил 0 переходлт в поколение 1 (увеличивал его размер); 
поколение 0 пустеет 
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На рисунке видно, что поколение 1 постепенно растет. Допустим, поколение 1 
вћфосло до таких размеров, что все его обвектм в совокупности превмсили порого- 
вое значение. В зтот момент приложение продолжает работатБ (потому что уборка 
мусора толбко что завершиласБ) и начинает размегцение в памити обЂектов P—S, 
которБге заполнигот поколение 0 до его порогового значении (рис. 21.10). 
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Рис. 21.10. Новме обвектБ! размеиденм в поколении 0, 
в поколении 1 поавилосв болише мусора 

При попБгтке приложении разместитБ обвект Т поколение 0 заполнпетси и на- 
чинаетсл уборка мусора. Однако на зтот раз уборгцик мусора обнаруживает, что 
место, заннтое обвектами, превБгсило пороговое значение. После несколБКих опе- 
рации уборки мусора в поколении 0 велика вероитностБ, что несколБКО обвектов 
в поколении 1 стали недоступнБши (как в нашем примере). Позтому теперБ убор- 
гцик мусора провернет все о 6 б 6 ктб 1 поколении 1 и 0. После уборки мусора в обоих 
поколенгшх куча вбшлидит так, как показано на рис. 21.11. 


D 

F 

1 

N 

0 

Q 

S 


Hl - lh 


Поколение 2 Поко- Поколение 0 

ление 1 


Рис. 21.11. Вид кучи после четмрех операции уборки мусора: внжившие обвектн 
из поколенич 1 переходлт в поколение 2, вБ 1 жившие обЂек™ из поколенип 0 
переходлт в поколение 1, поколение 0 снова пусто 


Все вБ 1 Жившие о 6 ђсктб 1 поколенин 0 теперБ находлтсн в поколении 1, а все 
вБгжившие о 6 б 6 ктб 1 поколенгш 1 — в поколении 2. Как всегда, сразу после уборки 
мусора поколение 0 пустеет: в нем будут размегцатБСн новбш обЂектБг В поколе- 
нии 2 находлтсн обЂектБц провереннБ1е уборгциком мусора не менБше двух раз. 
Операции уборки мусора может 6 б 1 тб много, но обвектБ 1 поколенин 1 провершотси 
толбко тогда, когда их суммарнБпг размер достигает порогового значенин — до зтого 
о 6 б 1 чно проходит несколБКО операции уборки мусора в поколении 0. 

Управлнеман куча поддерживает толбко три поколенгш: 0,1 и 2. Поколешш 3 не 
сугцествует 1 . При инициализации в CLR устанавливаетси пороговое значение длн 
всех трех поколении. Уборгцик мусора CLR нвлнетсн самонастраивакзгцимсн, то естБ 
в процессе работБ 1 он анализирует функционалБностБ приложенин и адаптируетси. 
Например, если приложение создает множество обвектов и полБзуетси ими оченв 




Статическии метод MaxGeneration класса System.GC возврагцает 2. 
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недолго, уборка мусора в поколении 0 позволнет освободитБ много памити. На 
самом деле, в поколении 0 можно освободитБ памнтБ всех обБектов. 

Если уборгцик видит, что после уборки мусора в поколении 0 остаетсн оченв мало 
ВБ 1 ЖИВШИХ обвектов, он может снизитб порог длн поколенин 0. В зтом случае уборка 
мусора будет вбшолннтбсн чагце, но зто менБше загрузит уборгцик, позтому рабочии 
набор процесса останетсн неболБшим. В сугцности, если все обвектвг поколенич 0 
станут мусором, уборгцику не придетси даже дефрагментироватБ памитБ — доста- 
точно будет вернутБ указателБ NextOb jPtn в начало поколенич 0, чтобвг посчитатв 
уборку мусора законченнои. ЗамечателБНБги способ освобожденин памлти! 

ПРИМЕЧАНИЕ 

Уборидик мусора отлично работает с приложенилми, потоки которнх болБшунз частБ 
времени бездеиствукзт, находлсБ в верхнеи части стека. Когда у потока полвллетсл 
работа, он просБшаетсл, создает несколБко обвектов с коротким временем жизни, 
возвраидаетуправление и оплтб заснпает. Такал архитектура реализована во многих 
приложенилх. Например, в приложенилх с графическим интерфеисом программнБ 1 и 
поток интерфеиса проводитболБшукз частБжизни в цикле сообидении. Времл отвре- 
мени полБЗОвателБСОЗдаетвходнБ1еданнБ1е (собБ1тие касанил, мнши или клавиатурБ!), 
потокактивизируетсл, обрабатнваетввод и возвраидаетсл кожиданикз. Болбшинство 
обЂектов, созданннх дли обработки ввода, при зтом становлтсл ненужннми. 

Аналогичннм образом в сервернБ 1 х приложенилх о6бнно исполБзуетсл пул потоков, 
ожидакзидих поступленил запросов от клиента. При получении запроса создакзтсл 
новне обБектБ! дпл вБтолненил работн по порученикд клиента. Когда резулБтат за- 
проса возвраидаетсп клиенту, поток возвраидаетсл в пул, а все созданнме им обЂекти 
подлежат уничтоженикз. 


В то же времн, если после обработки поколенгш 0 уборгцггк мусора обнаруживает 
множество вбгживших обвектов, значит, удаетсн освободитв мало памлти. В зтом 
случае уборгцик мусора может подннтб порог длн поколенин 0. В резулнтате уборка 
мусора вБгполннетсн реже, но кажднги раз будет освобождатБСн значителБНБги обвем 
памнти. Кстати, если уборгцггк освобождает недостаточно памнти, перед генерггрова- 
нием исклгоченгш OutOfMemoryException он вБгполннет полнуго уборку мусора. 

Л привел пример того, как уборгцик динамически может изменчтв порог по- 
коленгш 0, но сходнбгм образом могут менитБСч пороги дли поколении 1 и 2. При 
уборке мусора в зтих поколенгшх уборгцик определлет, сколбко памити 6 бгло 
освобождено и сколбко обвектов осталосв. В зависимости от полученнвгх даннБгх 
он может увелггчггтБ илгг уменБшитБ пороггг длн зтих поколении, чтобнг повбгситб 
производителБностБ работБг приложенин. В итоге уборгцик мусора автоматически 
адаптггруетси к загрузке памнти, необходимои длл конкретного прггложенггн! 

ПоказаннБш далее класс GCNotification вкгдает собБгтие пргг уборке мусора 
в поколении 0 или поколенгш 2. По зтому собвгтиго можно податв звуковои сигнал 
гглгг вбгчислггтб, сколбко временгг прошло между уборками, какои обвем памнти бвгл 
ввгделен гг т. д. ДаннБги класс позволнет проанализироватв код приложенгш, чтобнг 
лучше понитб, каким образом оно исполнзует памнтБ: 
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public static class GCNotification { 

private static Action<Int32> s_gcDone = null; // Поле собмтил 

public static event Action<Int32> GCDone { 
add { 

// Если зарегистрированнме делегатн отсутствугатЈ начинаем оповешение 
if (s_gcDone == null) { new GenObject(0); new GenObject(2); } 
s_gcDone += value; 

} 

remove { s_gcDone -= value; } 


private sealed class GenObject { 
private Int32 m_generation; 

public GenObject(Int32 generation) { m_generation = generation; } 

~GenObject() { // Метод финализации 

// Если обцект принадлежит нужному нам поколенига (или внше), 

// оповешаем делегат о вшполненнои уборке мусора 
Action<Int32> temp = Volatile.Read(ref s_gcDone); 
if (temp != null) temp(m_generation); 

} 

// Продолжаем оповешениеЈ пока остаетсл хотц один зарегистрированнми 
// делегат, домен приложении не вшгружен и процесс не завершен 
if ((s_gcDone != null) 

&& ! AppDomain.CurrentDomain.IsFinalizingForUnload() 

&& !Environment.HasShutdownStarted) { 

// Длл поколенил 0 создаем обцект; длл поколенил 2 воскрешаем 
// обцект и позволлем уборшику вћвватц метод финализации 
// при следугашеи уборке мусора длл поколенил 2 
if (m_generation == 0) new GenObject(0); 
else GC.ReRegisterForFinalize(this); 

} else { /* Позволлем обцекту исчезнутц */ } 

} 

} 

} 

Запускуборки мусора 

Как вм уже знаете, CLR запускает уборку мусора, когда обнаруживает, что обвем 
поколенин 0 достиг своего порогового значенин. Зто самаи распространеннан при- 
чина запуска уборки мусора, однако естБ и другие: 

□ Вмзов статического метода Collect обвекта System.GC. Код нвно указмвает, 
в какои момент должна 6 мтб вмполнена уборка мусора. Хотл Microsoft реши- 
телБно не рекомендует исполБЗОватБ зтот метод, иногда принудителБнан уборка 
мусора в приложении может 6 б 1 тб оправдана. Зтот способ рассматриваетсл 
позднее в зтои главе. 

□ Windows сообшает о нехватке памнти. CLR исполБзует функции Win32 Cre- 
ateMemoryResourceNotification и QueryMemoryResourceNotification длн 
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контролн состоннин памнти системм. Если Windows сообшает о недостаточном 
обкеме свободнои памлти, CLR запускает уборку мусора, чтобм избавитБСн от 
неисполБзуемБгх обвектов и сократитв размер рабочего набора процесса. 

□ ВБ1грузка домена приложенин. При вБ 1 грузке домена приложенгш CLR вбн 
полниет полнуго уборку мусора длн всех поколении. ДоменБ 1 приложении рас- 
сматриваготсн в главе 22. 

□ Завершение работБ1 CLR. CLR завершает работу при нормалвном завер- 
шении процесса (по сравнениго, например, с внешним завершением работБ 1 
из Диспетчера задач). Во времи заверенил CLR считает, что в процессе нет 
корневБ 1 х ссбшок; обвектам предоставлнетсл возможностб вб1полнитб очистку, 
но CLR не пБ 1 таетси дефрагмеитироватБ или освобождатБ памлтв, потому 
что после завершенил всего процесса Windows автоматически освобождает 
всго его памитБ. 


БолБшие обвектм 

Сугцествует егце один путв повБшенин бБКтродеиствин, о котором стоит рассказатв. 
CLR делит обвектБ 1 на малнш и болБшие. До настонгцего момента рассматривалисБ 
толбко малБге обвектБ 1 . ЛгобБге обвектБ 1 размером 85 000 баит и более считаготси 
болБшими 1 . CLR работает с 6 олбшими обвектами по несколнко отличагогцимсл 
правилам: 

□ Памнтв длн них вБгделнетсн в отделвнои части адресного пространства процесса. 

□ К болвшим обвектам не применнетсл сжатие, так как на их перемегцение в памнти 
потребуетсн слишком много процессорного времени. Возможнан фрагментацгш 
адресного пространства между болвшими обвектами может привести к ввгдаче 
исклгоченгш OutOfMemoryException. В будугцих версгшх CLR болвшие обвектБ 1 
могут участвоватБ в сжатии. 

□ Болвшие обвектБг всегда считаготсл частвго поколенгш 2 , позтому их следует 
создаватБ лишб длн ресурсов, которвге должнбг житб долго. Размегцение в памнти 
короткоживугцих болвших обвектов приведет к необходггмости частои уборкгг 
мусора в поколении 2 , что снижает производителвностБ. 06 бгчно в болвших 
обвектах хранитси болкшие строки (например, XML илгг JSON) или массивкг 
баитов, ггсполвзуемБге в операцгшх ввода/ввгвода — например, при чтенигг даннвгх 
из фаила или сети в буфер длн последугогцеи обработки. 

Всеи механизмвг абсолготно прозрачннг длн разработчика. Вбг можете просто 
забнгтБ об ггх сугцествовании до тех пор, пока в программе не возникнет какал-нибудБ 
аномалБнаи ситуации (например, фрагментации адресного пространства). 


1 В будугцем пороговБги размер обвекта, при котором он считаетсл болБшим, может 6бгтб 
изменен. Не следует считатБ значение 85 000 константои. 
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Режимм уборки мусора 

При запуске CLR вмбираетсл один из режимов уборки мусора, которми не может 
6мтб изменен до завершенин процесса. Сушествует два основнбш режима уборки 
мусора: 

□ Режим рабочеи станции. Зтот режим настраивает уборку мусора длл при- 
ложении на стороне клиента. Он оптимизирован длл минимизации времени 
приостановки потоков приложешш, что 6 б 1 не раздражатБ полБЗОвателл. Уборндик 
предполагает, что на компвготере работагот другие приложенгш, и старастси не 
заниматБ слишком много ресурсов процессора. 

□ Режим сервера. Зтот режим оптимизирует уборку мусора длл приложении на 
стороне сервера. Уборгцик предполагает, что на машине не запугцено никаких 
сторонних приложении (клиентских или сервернвгх), позтому все ресурсвг про- 
цессора можно броситн на уборку мусора. В зтом режиме управлнеман куча раз- 
бираетсн на несколвко разделов — по одному на процессор. Изначалвно уборгцик 
мусора исполБзует один поток на один процессор. Каждкги поток вБшолннетсн 
в собственном разделе одновременно с другими потоками. Такои подход хорошо 
работает в случае приложении с единообразнвш поведением рабочих потоков. 
Функцгш работает на компвготерах с несколБкими процессорами; толбко в зтом 
случае параллелвнаи обработка потоков позволнет получитв прирост произво- 
дителБности. 

По умолчаниго приложенгш запускаготси в режиме рабочеи станции с вклгочен- 
нбш режимом параллелБнои уборки мусора. А сервернБге приложенгш (например, 
ASRNET или SQL Server), обеспечивагогцие хостинг CLR, могут потребоватв за- 
грузки режима сервера. Однако если серверное приложение запускаетсл на одно- 
процессорнои машине, CLR всегда исполБзует режим рабочеи станции. Автономное 
приложение может приказатв CLR исполБЗОватБ сервернБги уборгцик мусора путем 
создангш конфигурационного фаила (о том, как ото сделатк, рассказБгвалосБ в гла- 
вах 2 и 3), содержагцего злемент gcServer. Вот пример конфигурационного фаила: 

<configuration> 

<runtime> 

<gcServer enabled="true"/> 

</runtime> 

</configuration> 

Узнатв, запугцена ли среда CLR в серверном GC -режиме, можно при помогци 
логического своиства IsServerGC класса GCSettings, предназначенного толбко 
длн чтенгш: 

using System; 

using System.Runtime; // GCSettings находитсл в зтом пространстве имен 



Поколенил 571 


public static class Program { 
public static void Main() { 

Console.WriteLine( 

"Application is running with server GC=" + GCSettings.IsServerGC); 

} 

} 

Кроме двух основнмх режимов, у уборвдика мусора сушествует два подрежима: 
параллелБнми (исполБзуемБН! по умолчаниго) и непараллелБНБпт. В параллелБном 
режиме у уборвдика мусора еств дополнителБНБ1и фоновБП! поток, вбшолннговдии 
пометку обвектов во времи работБ 1 приложешш. Когда поток размегцает в пами- 
ти обвект, вБ13Бшагопдии превБ1шение порога длл поколенгш 0, уборгцик спачала 
приостанавливает все потоки, а затем определлет поколенгш, в которвгх нужно 
вбшолнитб уборку мусора. Если уборгцик должен собратн мусор в поколении 0 
или 1, он работает как обвшно, но если нужно собратв мусор в поколении 2, раз- 
мер поколенгш 0 увеличиваетсн вБпне порогового, чтобвг разместитв новбш обвект, 
а затем исполнение потоков приложенгш возобновлчетсл. 

Пока работагот потоки приложенгш, отделвнБги поток уборгцика с нормалБнкш 
приоритетом находит все недоступнвге обвектБ 1 в фоновом режиме. После того 
как обвектБ1 будут обнаруженБр уборгцик приостанавливает все потоки и решает, 
нужно ли дефрагментироватв памнтБ. Если он принимает положителБное решенне, 
памнтБ дефрагментируетсл, ссбдлки корнеи исправлиготси, а исполнение потоков 
приложенгш возобновллетсл — такан уборка мусора обвшно проходит бвштрее, 
так как переченв недоступнБгх обвектов создаетсл заранее. Однако уборгцик мо- 
жет отказатвси от дефрагментации памлти, что, на самом деле, предпочтителБнее. 
Если свободнои памити много, уборгцик не станет дефрагментироватв кучу — зто 
повБгшает бБгстродеиствие, но увеличивает рабочии набор приложенгш. Прибегаи 
к параллелБнои уборке мусора, приложение обкшно расходует болнше памнти, чем 
при непараллелБнои уборке. 

Можно запретитБ CLR исполБЗОватБ режим параллелБнои уборки мусора, 
создав конфигурационнБпг фаил приложенгш, содержагции злемент gcConcurrent 
(см. главБг 2 и 3). Вот пример такого фаила: 

<configuration> 

<runtime> 

<gcConcurrent enabled="false"/> 

</runtime> 

</configuration> 

Хотл конфигурацгш GC -режима не может 6бгтб изменена до завершенгш про- 
цесса, приложение может контролироватв уборку мусора при помогци своиства 
GCLatencyMode класса GCSettings. Зтому своиству могут присваиватБСл ./i гоб i>ie 
значенгш из перечисленгш GCLatencyMode. ВариантБ! перечисленБ! в табл. 21.1. 
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Таблица 21.1. Значенип, определеннме в перечислении GCLatencyMode 


Значение 

Описание 

Batch (по умолчаншо ис- 
полћзуетсл длл серверно- 
го режима) 

Отклгочает параллелвнук) уборку мусора 

Interactive (по умолчаншо 
исполћзуетсл длл режима 
рабочеи станции) 

Вклгочает параллелБнуго уборку мусора 

LowLatency 

В режиме рабочеи станции зтот скрБ1ТБ1и режим исполб- 
зуетсл длл кратковременнБгх, критичнБ1х по времени опе- 
рации (например, анимации), длл которвхх уборка мусора 
в поколении 2 из-за сниженгш производителвности может 
оказатБсн неприемлемои 

SustainedLowLatency 

ИсполБзуетсл длл предотврашенин долгих пауз уборки 
мусора во времл ввшолненгш приложенгш. Блокирукнцал 
уборка мусора поколенгш 2 запретцаетсл при наличии сво- 
боднои памлти. Полвзователи таких приложении скорее 
предпочтут установитв на компБГОтере дополнителБнуго 
памлтБ, что6бг избежатБ пауз. Пример приложенгш такого 
рода — приложение длл торговли на бирже, которое долж- 
но немедленно реагироватв на изменение ценвг 


Режим LowLatency требует дополнителћнмх понснении. Обмчно его вклгочагот 
длл реализации операции, длл котормх важно времи вмполненил, а затем воз- 
врашагот режим Batch или Interactive. Однако в режиме LowLatency уборшик 
мусора деиствителБно обходит вниманием поколение 2, так как зто может заннтБ 
много времени. Разумеетсл, если bbi ввмовете метод GC.Collect(), поколение 2 
также отправитсн в мусор. То же самое произоидет, если Windows <<пожалуетсл» 
CLR на недостаток системнои памнти (зтот вопрос обсуждалсн ранее в зтои главе). 

В режиме LowLatency приложение может вввдаватБ исклгочение OutOfMemory- 
Exception. Соответственно, можно порекомендоватв вклгочатБ зтот режим на мак- 
сималБно короткое времн, избегатв размегценин в памнти многих обвектов, а также 
болвших обвектов и возврагцатвсл к режимам Batch и Interactive при помогци 
области ограниченного вБшолненгш (см. главу 20). Также помните, что режим 
LowLatency нвлнетсл настроикои уровнн процесса и потоки могут 6bitb запугценБ 1 
параллелБно. Зти потоки могут даже мсннтб даннуго настроику в процессе ее ис- 
полвзовангш другим потоком. В зтом случае bbi можете добавитв обновлнгогциисн 
счетчик (управлнемБш при помогци методов Interlocked). Вот пример корректного 
исполБЗОвангш режима LowLatency: 

private static void LowLatencyDemo() { 

GCLatencyMode oldMode = GCSettings.LatencyMode; 
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System.Runtime.CompilerServices.RuntimeHelpers.PrepareConstrainedRegions(); 
try { 

GCSettings.LatencyMode = GCLatencyMode.LowLatency; 

// Здеси вмполнлетсл код 

} 

finally { 

GCSettings.LatencyMode = oldMode; 

} 

} 

Программное управление уборшиком мусора 

Тип System.GC позволиет приложениго напрнмуго управлитБ уборпдиком мусора. 
Длн начала замечу, что узнатБ максималБное поколение, поддерживаемое управли- 
емои кучеи, можно, прочитав значение своиства GC .MaxGeneration. Зто своиство 
всегда возврашает 2. 

Что 6 б 1 заставитБ уборгцика мусора провести уборку, следует вБ13ватв метод 
Collect класса GC. При вБ130ве можно указатв поколение, в котором нужно вбшол- 
нитб уборку мусора, параметр GCCollectionMode и логическии признак вкшолне- 
нин блокиругогцеи (непараллелБнои) или фоновои (параллелБнои) уборки мусора. 
Сигнатура самои сложнои перегруженнои версии Collect вб 1 гллдит так: 

void Collect(Int32 generation, GCCollectionMode mode, Boolean blocking) 

Различшле значенгш параметра GCCollectionMode описанБ! в табл. 21.2. 


Таблица 21.2. Значении параметра GCCollectionMode 


Значение 

Описание 

Default 

Аналогично вмзову метода GC.Collect без флагов. В настонгцее 
времн зквивалентно передаче параметра Forced, но в следугогцих 
версилх CLR ситуацил может изменитвсл 

Forced 

Инициирует уборку мусора длл всех поколении вплотб до ука- 
занного вами, вклгочал и само зто поколение 

Optimized 

Уборка мусора осугцествллетсн толвко при условии качественно- 
го конечного резулвтата, вмражагогцегосл либо в освобождении 
болћшого обвема памнти, либо в уменБшении фрагментации. 

В противном случае вбгзов метода в зтом режиме не дает никако- 
го зффекта 


Обмчно следует избегатБ ВБ 13 ова лгобмх методов Collect: лучше не вмеши- 
ватвси в работу уборгцика мусора и позволитб ему самостонтелБно настраиватБ по- 
роговБге значенин длн поколении, основБшансБ на реалБном поведении приложенин. 
Однако при написании приложентш с консолбнбш или графическим интерфеисом 
его код <<владеет» процессом и CLR в зтом процессе. В подобнвш приложенгшх 
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порои следует собиратБ мусор принудителБно во вполне определенное времн. Зто 
можно сделатБ при помотци метода GCCollectionMode в режиме Optimized. РежимБ 1 
Def ault и Forced о6бшно исполБзугот длл отладки и тестированин. 

Например, имеет смбгол вбгобшлтб метод Collect, если толбко что произошло 
некое разовое собвтте, которое привело к уничтожениго множества старвш обвектов. 
Вб130в Collect в такои ситуации оченв кстати, ведк основаннБ 1 е на прошлом опнгае 
прогнозБ1 уборгцика мусора, скорее всего, длн разовБ1х со6б1тии окажутсл нсточнбши. 
Например, в приложении имеет смбгол вбшолнитб принудителБнуго уборку мусора 
во всех поколенгшх после инициализации приложенгш или сохраненгш полвзова- 
телем фаила с даннвши. Когда на веб-странице размегцаетсл злемент управленгш 
Windows Form, полнан уборка мусора ввшолннетсл при каждои вкггрузке страницБк 
Не нужно вручнуго вБгзвшатБ метод Collect, что6бг сократитБ времи отклика при- 
ложенгш; вБгзвшаите его, что6бг уменБшитБ рабочии набор процесса. 

В некоторБгх приложенгшх (особенно зто касаетсл сервернкгх приложенгш, хранн- 
гцих в памнти множество обвектов) времн на полнуго уборку мусора (до второго поко- 
ленгш) оказБшаетсн слишком болБшим. Более того, если уборка мусора длитсн слиш- 
ком долго, может завершитБСн времл ожидангш клиентских запросов. Чтобвг избежатв 
подобшлх ситуации, в классе GC имеетсл метод RegisterForFullGCNotification. 
С его помогцбго и при исполБЗОвангш дополнителБнвгх вспомогателБНБгх методов 
(WaitForFullGCApproach, WaitForFullGCComplete и CancelFullGCNotification) 
можно оповеститв приложение о том, что уборгцик мусора близок к вБшолнениго 
полнои уборки. В резулБтате приложение сможет внгзватБ метод GC.Collect длл 
принудителБнои уборки мусора в более подходлгцее времн или свлжетси с другими 
серверами, чтобвг лучше распределитв клиентские запросБг. ДополнителБнуго ин- 
формациго об зтих методах вбг можете наити в документации на .NET Framework 
SDK. Имеите в виду, что методвг WaitForFullGCApproach и WaitForFullGCComplete 
всегда вБгзвшаготсн вместе, так как CLR обрабатвшает их попарно. 

Мониторинг исполБЗОванин памвти приложением 

Сугцествугот методвг, которБге можно внгзватБ длн наблгоденгш за работои уборгцика 
мусора в процессе. Так, следугогцие статические методвг класса GC вБгзвшаготсл длн 
вБшсненгш числа операции уборки мусора в конкретном поколении или длн обвема 
памлти, занцтого в даннвш момент обвектами в управлнемои куче. 

Int32 CollectionCount(Int32 generation); 

Int64 GetTotalMemory(Boolean forceFullCollection); 

Чтобвг вбшолнитб профилирование конкретного блока кода, н часто вставлнго 
до и после него код, вБгзБшагогции зти методБг, а затем вбгчислиго разностБ. Зто по- 
зволнет мне судитв о том, как зтот блок кода сказБгваетси на рабочем наборе про- 
цесса, и узнатв, сколбко операции уборки мусора произошло при исполненгш зтого 
блока кода. Если показатели вБгсокие, значит, нужно поработатк над оптимизациеи 
алгоритма в блоке кода. 
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Можно также узнатБ, сколбко памнти расходуетсл отделБНБ 1 м доменом при- 
ложении. О том, как зто сделатћ, вб 1 узнаете в главе 22. 

В ходе установки ,NET Framework устанавливаетсл также набор счетчиков 
производителБности, которБ 1 е позволнгот собиратв в реалвном времени самвк 
разнообразнБ 1 е статистические даннБ 1 е о CLR. Зти даннБ 1 е можно просматриватБ 
с помогцБК) утилитБ 1 PerfMon.exe или системного монитора из состава Windows. 
Прогце всего получитв доступ к системному монитору, запустив утилиту PerfMon. 
ехе и гцелкнув на кнопке + панели инструментов; на зкране понвлнетсл диалоговое 
окно Add Counters, показанное на рис. 21.12. 




□ *»•4 


Рис. 21.12. Счетчики памлти .NET CLR в окне PerfMon.exe 


Длл мониторинга уборки мусора в CLR ввгберите обвект производителБности 
.NET CLR Метогу, затем укажите в списке нужное приложение. В завершение bbi- 
берите набор счетчиков длл мониторинга, гцелкните на кнопке Add, затем — на 
кнопке ОК. Теперв системнБП! монитор будет в реалвном времени строитв график 
вБ 1 бранного статистического показателл. Что 6 б 1 узнатБ, что означает счетчик, вбн 
делите его и установите флажок Show Description. 

Егце один замечателБНБИ! инструмент длл анализа исполБЗОванин памити 
и производителБности приложенин назБшаетсл PerfView. Он позволнет собиратв 
журналБ 1 ETW (Event Tracing for Windows) и обрабатншатБ их. Bhi можете наити 
его в Интернете по строке поиска <<PerfView». Наконец, можно восполвзоватБСи 
отладочнБш расширением (SOS.dll), помогаклцим при проблемах с памнтБК) и дру- 
гих проблемах CLR. Зто расширение позволнет узнатв, сколбко памнти вБвделено 
дли процесса в управлиемои куче, ввгвести все обБектвц зарегистрированнБге дли 
финализации и помегценнБге в очередв, просмотретБ записи в таблице GCHandle как 
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дли домена приложении, так и длн всего процесса, проверитБ корни, сохраннклцие 
оођскт в куче живмм, и многое другое. 


Освобождение ресурсов при помснци 
механизма финализации 

Итак, мм познакомилиск с азами уборки мусора и управлиемои кучеи, а также тем, 
как уборгцик мусора освобождает памнтБ обЂекта. К счасткк), болБшинству типов 
длл работм требуетсл толбко памитк, но естћ и типм, котормм помимо памлти не- 
обходимм системнме ресурсм. 

Например, типу System.IO.FileStream нужно открмтБ фаил (системнми ре- 
сурс) и сохранитБ его дескриптор. Затем при помогци зтого дескриптора методм 
Read и Write данного типа работагот с фаилом. Аналогично, тип System . Threading . 
Mutex открмвает мБготекс, нвлнгогцгшсн о6ђсктом ндра Windows (системнми ресурс), 
и сохранлет его дескриптор, которми исполЂзует при вмзове методов обвекта Mutex. 

Если тип, исполЂзугогции системнми ресурс, будет уничтожен в ходе уборки му- 
сора, занимаеман обвектом памнтЂ вернетсн в управлнемуго кучу; однако системнми 
ресурс, о котором уборгцику мусора ничего не известно, будет потернн. Разумеетсн, 
зто нежелателЂно, позтому CLR поддерживает механизм финализации (fmalization), 
позволнгогции обвекту вмполнитђ корректнуго очистку, прежде чем уборгцик мусора 
освободит заннтуго им памнтм Лгобои тип, исполЂзугогции системнми ресурс (фаил, 
сетевое соединение, сокет, мЂготекс и т. д.), должен поддерживатЂ финализациго. 
Когда CLR определнет, что обвект стал недоступнмм, ему предоставлнетсн возмож- 
ностђ вмполнитђ финализациго с освобождением всех задеиствованнмх системнмх 
ресурсов, после чего обвект будет возврагцен в управлиемуго кучу. 

Всеобгции базовми класс Sy stem . Ob ј ect определнет загцигценнми виртуалЂнми 
метод с именем Finalize. Когда уборгцик мусора определнет, что обвект подлежит 
уничтожениго, он вмзмвает метод Finalize зтого обвекта (если он переопределен). 
Группа проектировгциков C# из Microsoft посчитала, что метод финализации отли- 
чаетсн от осталЂнмх и требует специалЂного синтаксиса в нзмке программировангш 
(по аналогии с тем, как в C# специалЂнми синтаксис исполЂзуетсн длн определенгш 
конструктора). Позтому длн определенгш метода финализации в C# перед именем 
класса нужно добавитЂ знак тилђдм (~): 

internal sealed class SomeType { 

// Метод финализации 
~SomeType() { 

// Код метода финализации 

} 

} 

Скомпилировав зтот код и проверив полученнуго сборку с помогцђго утилитм 
ILDasm.exe, вм увидите, что компшштор C# внес в метаданнме зтого модулл загци- 
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meiim.iii метод с именем Finalize. При изучении IL -кода метода Finalize также 
становитси нсно, что код в теле метода генерируетсл в блок try, а вмзов метода 

base . Finalize — в блок f inally. 


ВНИМАНИЕ 

Разработчики с опмтом программированил на С++ заметлт, что специалвнвм син- 
таксис, ncnoab3yeMbiH в C# длл определенил метода финализации, напоминает 
синтаксис деструктора С++. Деиствителвно, в предмдутих версилх спецификации 
C# зтот метод назмвалсл деструктором (destructor). Однако метод финализации 
работает совсем не так, как неуправллемвш деструктор С++, что сбивает с толку 
многих разработчиков, переходлтих с одного H3biKa на другои. 

Беда в том, что разработчики ошибочно полагакзт, что исполизование синтаксиса 
деструктора означает в C# детерминированное уничтожение обвектов типа, как 
зто происходит в С++. Flo CLR не поддерживает детерминированное уничтожение, 
позтому C# не может предоставиљ зтот механизм. 


Методм Finalize вмзмваготсн при завершении уборки мусора длн обвектов, 
которме уборгцик мусора определил дли уничтоженин. Зто означает, что памнтБ 
таких обвектов не может 6бгтб освобождена немедленно, потому что метод Finalize 
может вбшолнитб код с обрагцением к полго. Так как финализируемБш обвект 
должен пережитБ уборку мусора, он переводитсн в другое поколение, вследствие 
чего такои обвект живет намного долвше, чем следует. Ситуацин не идеалнна в от- 
ношении исполБЗОвании памнти, позтому финализации следует по возможности 
избегатв. Проблема усугубллетсл тем, что при преобразовании поколенин фина- 
лизируемвгх обвектов все обвектБг, на которнге они ссБшаготсл в своих полнх, тоже 
преобразуготси, потому что они должнбг продолжатБ свое сугцествование. Итак, 
стараитесв по возможности обоитисв без созданин финализируемБгх обвектов 
с полими ссбшочного типа. 

Также следует учитншатБ, что разработчик не знает, в какои именно момент 
будет вБгполнен метод Finalize, и не может управлнтБ его вБгполнением. Методнг 
Finalize вбшолннготсн при ВБГполнении уборки мусора, которан может произоити 
тогда, когда ваше приложение запросит дополнителвнуго памитБ. Кроме того, CLR 
не дает никаких гарантии относителнно поридка вкгзова методов Finalize. Итак, 
следует избегатв написанинметодов Finalize, обрагцагогцихсик другим обвектам, 
ТИПБ1 которБгх определнгот метод Finalize; может оказатнси, что последние уже 
прошли финализациго. Тем не менее ничто не мешает вам обрагцатвси к зкзем- 
плнрам значимБгх типов или обвектам ссбшочнбгх типов, не определнгогцих метод 
Finalize. Также будвте внимателБНБг при внгзове статических методов, потому что 
зти методвг могут обрагцатБСл к обвектам, уже прошедшим финализациго; поведение 
статического метода становитси непредсказуемвгм. 

Длн вБгзова методов Finalize CLR исполвзует специалБНБпг вБгсокоприоритет- 
нбш поток. Таким образом предотврагцаготсн ситуации взаимнои блокировки, воз- 
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можнме в обмчнмх условинх 1 . Если метод Finalize блокируетсн (например, входит 
в бесконечнми цикл или ожидает обвекта, которми никогда не будет освобожден), 
специалБнми поток не сможет вмзмватБ методм Finalize. Даннан ситуацгш краине 
нежелателБна, потому что приложение не сможет освободитБ памнтБ, занимаемуго 
финализируемБгми обБектами. Если метод Finalize вкгдает необработанное ис- 
клгочение, процесс завершаетсл; перехватитв такое исклгочение невозможно. 

Как видите, исполвзование методов Finalize свизано с многочисленнвгми 
оговорками и требует значителвнои осторожности от разработчика. Зти методнг 
предназначенБг исклгочителБно длл освобожденгш системнвгх ресурсов. Чтобвг 
упроститв их исполБЗОвание, л рекомендуго по возможности обоитисв без пере- 
определенгш метода Finalize класса Object; вместо зтого лучше исполвзоватБ 
вспомогателБНБш класс из библиотеки FCL. Зтот класс переопределлет Object 
и вБшолниет рлд дополнителБНБгх операции, о которнгх будет рассказано позже. 
Вбг можете создатБ собственнБге классБг, производнБге от него и наследугогцие все 
вспомогателБНБге операцгш. 

Если вб 1 создаете управллемБги тип, исполБзугогции системнБпг ресурс, соз- 
даите класс, производнБш от специалБного базового класса System. Runtime. 
InteropServices . SafeHandle, которвш вбггллдит примерно так (комментаргш 
в коде метода мои): 

public abstract class SafeHandle : CriticalFinalizerObject^ IDisposable { 

// Зто дескриптор системного ресурса 
protected IntPtr handle; 

protected SafeHandle(IntPtr invalidHandleValue, Boolean ownsHandle) { 
this.handle = invalidHandleValue; 

// Если значение ownsHandle равно true, то системнми ресурс закрмваетсл 
// при уничтожении обБекта, производного от SafeHandle, 

// уборшиком мусора 

} 

protected void SetHandle(IntPtr handle) { 
this.handle = handle; 

} 

// Нвное освобождение ресурса вмполнлетсв вмзовом метода Dispose 
public void Dispose() { Dispose(true); } 

// ЗдесБ подоидет стандартнав реализацил метода Dispose 
// Настолтелцно не рекомендуетсл переопределлтБ зтот метод! 
protected virtual void Dispose(Boolean disposing) { 

// B стандартнои реализации аргумент, Bbi3biBawinnn метод 
// Dispose, игнорируетсл 

// Если ресурс уже освобожден, управление возврашаетсв коду 
// Если значение ownsHandle равно false, управление возврашаетсл 
// Установка флага, означаклцего, что зтот ресурс бил освобожден 


1 Возможно, в будутцих версинх CLR длл повншенил производителвности будут исполб- 
зоватвсн множественнБге потоки финализации. 



Освобождение ресурсов при помоиди механизма финализации 579 


// Вмзов виртуалвного метода ReleaseHandle 

// Вмзов GC.SuppressFinalize(this), отменлтции внзов метода финализации 
// Если значение ReleaseHandle равно true, управление возврацаетсл коду 
// Если управление передано в зту точкУј 

// запускаетсл ReleaseHandleFailed Managed Debugging Assistant (MDA) 

} 

// Здесч подходит стандартнал реализацил метода финализации 
// Настолтелцно не рекомендуетсл переопределлтц зтот метод! 

~SafeHandle( ) { Dispose(false) ; } 

// Производнми класс переопределлет зтот методЈ 
// 4To6bi реализоватц код освобожденил ресурса 
pnotected abstract Boolean ReleaseHandle(); 

public void SetHandleAsInvalid() { 

// Установка флага., означаккцегоЈ что зтот ресурс бнл освобожден 
// Вмзов GC.SuppressFinalize(this), отменлкнции внзов метода финализации 

} 

public Boolean IsClosed { 
get { 

// Возврацение флага, показмванкцегоЈ бмл ли ресурс освобожден 

} 

} 

public abstract Boolean Islnvalid { 

// Производнни класс переопределлет зто своиство 
// Реализацил должна вернутц значение true, если значение 
// дескриптора не представллет ресурс (обћпно зто значит, 

// что дескриптор равен 0 или @1) 
get 

} 

// Зти три метода имеит отношение к безопасности и подсчету ссшлок 
// Подробнее о них рассказшваетсл в конце зтого раздела 
public void DangerousAddRef(ref Boolean success) {...} 
public IntPtr DangerousGetHandle() {...} 
public void DangerousRelease() {...} 

} 

Рассматриван класс Saf eHandle, прежде всего нужно отметитБ, что он наследует 
от класса CriticalFinalizerObject, определенного в пространстве имен System . 
Runtime . ConstrainedExecution. Зто гарантирует «особоеобрашение» со сторонБ1 
CLR к зтому классу и другим, производнћш от него классам. В частности, CLR на- 
деллет зтот класс тремн интереснБши особенностлми: 

□ При первом создании лгобого обвекта, производного от типа Critical- 
FinalizerObject, CLR автоматически запускает JIT -компилитор, компили- 
рукпции все методБ1 финализации в иерархии наследованин. Компилнцгш 
зтих методов после созданил обвекта гарантирует, что системнБге ресурсБг 
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освободлтсл, как то. њко обвект станет мусором. Без немедленнои компилиции 
метода финализации может оказатБСн, что ресурс будет вБвделен и исполБЗОван, 
но не освобожден. При недостатке памнти CLR может не хватитв памнти длл 
компилнции метода финализации; в зтом случае метод не будет исполнен, что 
приведет к утечке системнБ 1 х ресурсов. Также ресурсБ 1 не будут освобожденБц 
если код в методе финализации содержит ссвшку на тип в другои сборке, котораи 
не бвша обнаружена CLR. 

□ CLR вБ13Б1вает метод финализации длн типов, производнвтх от CriticalFinalizer- 
Object, после вБ130ва методов финализации длл типов, непроизводнБ1х от 
CriticalFinalizerObject. Благодари зтому классБ 1 управлиемБ 1 х ресурсов, 
имегогцие метод финализации, могут успешно обрагцатвси к обвектам, произ- 
воднБгм от CriticalFinalizerObject, в их методах финализации. Так, метод 
финализации класса FileStream может сброситв даннБге из буфера памнти на 
диск в полнои уверенности, что дисковбш фаил егце не 6бш закрБгт. 

□ CLR вБгзБшает метод финализации длн типов, производнвгх от CriticalFinalizer- 
Object, если домен приложенгш 6бш авариино завершен управлнгогцим прило- 
жением (например, Microsoft SQL Scrvcr или Microsoft ASRNET). Зто гаранти- 
рует освобождение системнвгх ресурсов даже в том случае, когда управлнгогцее 
пргшожение болвше не доверпет работагогцему внутри него управлиемому коду. 

Также следует отметитв, что класс SafeHandle нвлиетсл абстрактнвгм: пред- 
полагаетсл, что разработчик создаст класс, производнБш от SafeHandle, которБпг 
переопределит загцигценнБги конструктор, абстрактнкш метод ReleaseHandle 
и абстрактное своиство Islnvalid метода доступа get. 

В Windows длл операции с системнвши ресурсами о6бгчно исполБзуготсл де- 
скрипторБг (32-разриднБге в 32-разриднБгх системах, 64-разриднБге в 64-разриднБгх 
системах). В классе SafeHandle определлетсл загцигценное поле IntPtr с именем 
handle. Болбшинство дескрипторов считаготсн недеиствителБНБши при равенстве 
ихзначенгшОили-1. Пространствоимен Microsoft.Win32.SafeHandles содержит 
егце один вспомогателБНБпг класс SafeHandleZeroOrMinusOnelsInvald вида: 

public abstract class SafeHandleZeroOrMinusOnelsInvalid : SafeHandle { 

protected SafeHandleZeroOrMinusOneIsInvalid(Boolean ownsHandle) 

: base(IntPtr.Zero, ownsHandle) { 

} 

public override Boolean Islnvalid { 
g6t { 

if (base.handle == IntPtr.Zero) return true; 
if (base.handle == (IntPtr) (-1)) return true; 
return false; 

} 

} 

} 
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Обратите внимание, что класс SafeHandleZeroOrMinusOnelsInvalid ивли- 
етсн абстрактнмм, позтому надо создатБ дочернии класс, которши переопреде- 
лит зашишеннми конструктор и абстрактнвш метод ReleaseHandle. На плат- 
форме Microsoft .NET Framework естБ несколБКО открмтмх классов, производ- 

нмх от SafeHandleZeroOrMunusOnelsInvalid, в числе котормх SafeFileHandle, 
SafeRegistryHandle, SafeWaitHandle и SafeMemoryMappedViewHandle. А так 
вмгллдит класс SafeFileHandle: 

public sealed class SafeFileHandle : SafeHandleZeroOrMinusOnelsInvalid { 
public SafeFileHandle(IntPtr preexistingHandle, Boolean ownsHandle) 

: base(ownsHandle) { 

base.SetHandle(preexistingHandle); 

} 

protected override Boolean ReleaseHandle() { 

// Сообцити Windows, что системнми ресурс нужно закрмтн 
return Win 32 Native.CloseHandle(base.handle) ; 

} 

} 

Класс SafeWaitHandle реализован сходнмм образом. Единственнои причинои 
длл созданил разнмх классов с похожими реализацгшми ивлпетсл обеспечение 
безопасности типов: компилнтор не позволит исполБЗОватБ фаиловми дескриптор 
в качестве аргумента метода, принимакнцего дескриптор блокировки, и наоборот. 
Метод ReleaseHandle класса SafeRegistryHandle вмзмвает Win32-^yHKmiro 
RegCloseKey. 

ЖалБ, что на платформе .NET Framework отсутствугот дополнителБНБге клас- 
СБ1, служагцие оболочкои различнБ1х системнБ1х ресурсов, например таких, как 

SafeProcessHandle, SafeThreadHandle, SafeTokenHandle, SafeLibraryHandle (его 
метод ReleaseHandle вБ13Б1вал 6bi Win32-^yHKunro FreeLibrary), SafeLocalAl- 
locHandle (его метод ReleaseHandle вБИБшал 6bi Win32-^yHKmno LocalFree) 
и т. п. 

Bce зти классБ 1 (а также некоторБге другие) естБ в библиотеке FCL. Однако они 
не предоставлнготсн длн открБ1того исполБЗОванин, нвлннсб внутренними классами 
сборок, в которБ 1 х они определнготсл. Microsoft не афиширует зти классБр что6б1 не 
вбшолннтб их полное тестирование и не тратитБ времи на их документирование. 
Если же вам придетси с ними столкнутБСи, рекомендуго восполБЗОватБСн утилитои 
ILDasm.exe или другим IL -декомпилнтором, что6б1 извлечБ код зтих классов и инте- 
грироватБ его в исходнбш текст программБг Все зти классБ1 тривиалБно реализуготсн 
и их несложно написатБ самостолтелБно. 

КлассБц п ро из в о днб 1 е от SafeHandle, чрезвБшаино полезнБ 1 — ведБ они гаран- 
тиругот освобождение системного ресурса в ходе уборки мусора. Стоит добавитБ, 
что у типа SafeHandle естБ еше две функционалБНБШ особенности. Во-первБ 1 х, 
когда производнБ1е от него типб! исполБзуготсл в сценарилх взаимодеиствин 
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с неуправлиеммм кодом, им гарантирован особми подход со сторонм CLR. Вот 
пример: 

using System; 

using System.Runtime.InteropServices; 
using Microsoft.Win32.SafeHandles; 

internal static class SomeType { 

[DllImport("Kernel32", CharSet=CharSet.Unicode, EntryPoint="CreateEvent")] 

// Зтот прототип неустоичив к сболм 
private static extern IntPtr CreateEventBad( 

IntPtr pSecurityAttributes, Boolean manualReset, 

Boolean initialState, String name); 

// Зтот прототип устоичив к сбовм 

[DllImport("Kernel32", CharSet=CharSet.Unicode, EntryPoint="CreateEvent")] 
private static extern SafeWaitHandle CreateEventGood( 

IntPtr pSecurityAttributes, Boolean manualReset, 

Boolean initialState, String name); 

public static void SomeMethod() { 

IntPtr handle = CreateEventBad(IntPtr.Zero, false, false, null); 

SafeWaitHandle swh = CreateEventGood(IntPtr.Zero, false, false, null); 

} 

} 

Обратите внимание, что прототип метода CreateEventBad возврагцает IntPtr, то 
естБ он возврагцает дескриптор в управлнемБш код. Подобного рода взаимодеиствин 
с неуправлнемБш кодом неустоичивБ 1 к сбонм. После вкшова метода CreateEventBad 
(создагогцего системнвп! ресурс со 6 б 1 тин) возможна ситуацин, когда исклгочение 
ThreadAbortException понвлнетсндо присвоенин дескриптора переменнои handle. 
В таких редких случалх в управлиемом коде образуетсн утечка системного ресурса. 
И собљгше можно закрвмБ толбко одним способом — завершив процесс. 

Класс SafeHandle устраннет зту потенциалБнуго утечку ресурсов. Обратите 
внимание, что прототип метода CreateEventGood возврагцает SafeWaitHandle, 
а не IntPtr. При ввгоове метода CreateEventGood CLR вБИБшает \\ђп32-функци io 
CreateEvent. Когда зта функцин возврагцает управление управлнемому коду, CLR 
«знает», что SafeWaitHandle нвлиетсл производнвгм от SafeHandle. Позтому CLR 
автоматически создает зкземплнр класса Saf eWaitHandle, передаван ему полученное 
от метода С reate Е vent значение дескриптора. Обновление обвекта SafeWait На ndle 
и присвоение дескриптора происходлт в неуправлиемом коде, которвш не может 
6бгтб прерван исклгочением ThreadAbortException. В резулвтате в управлиемом 
коде не может возникнутв утечка зтого системного ресурса. А в итоге обвект 
Saf eWaitHandle удаллетсн уборгциком мусора и вБгзБгваетсн его метод финализации, 
обеспечивагогцгш освобождение памлти. 

И наконец, классвг, производнБге от SafeHandle, гарантиругот, что никто не 
сможет восполБЗОватБСи возможнбгми брешами в системе безопасности. Проблема 
в том, что один из потоков может попБгтатвсн исполБЗОватБ системнБш ресурс, осво- 
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бождаемћш другим потоком. Зто назБшаетсл атакои с повторнкш исполБЗОванием 
дескрипторов. Класс SafeHandle предотврагцает зто нарушение безопасности благо- 
дарн подсчету ссбшок. В нем определено закркдтое поле, исполнндогцее ролк счетчика. 
Когда производному от Saf eHandle обвекту присваиваетсн корректнвш дескриптор, 
счетчик приравниваетсч к 1. Всикии раз, когда производнвш от SafeHandle обвект 
передаетсл как аргумент неуправлнемому методу, CLR автоматически увеличивает 
значение счетчика на единицу. Когда неуправлнемБш метод возврагцает управление 
управлнемому коду, CLR уменвшает значение счетчика на ту же величину. Напри- 
мер, вот как вбггллдит прототип \\чп32-ф\тпап1 п SetEvent: 

[DllImport( "Кегпе132" j ExactSpelling=true)] 

private static extern Boolean SetEvent(SafeWaitHandle swh); 

При вБгзове зтого методаи передаче ему ссбглки наобвект SafeWaitHandle CLR 
увеличивает значение счетчика перед вбгзовом и уменвшает значение счетчика 
сразу после вБгзова. Разумеетсл, операцгш со счетчиком вбшолннготсл способом, 
безопаснБш по отношениго к потокам. Как зто повБшгает безопасностБ? Если другои 
поток попБгтаетсн освободитБ системнБШ ресурс, оболочкои которого нвлнетсл о6б- 
ект SafeHandle, CLR узнает, что зто ему не разрешено, потому что даннБш ресурс 
исполБзуетсл неуправлнемои функциеи. Когда функцгш вернет управление про- 
грамме, значение счетчика будет приравнено к 0 и ресурс освободитсл. 

При написании или ввгзове кода, работагогцего с дескриптором (например, 
IntPtn), к нему можно обратитвсл из обвекта SafeHandle, но подсчет ссбшок при- 
детсл вбшолннтб ивно с помогцбго методов DangerousAddRef и DangerousRelease 
обвекта SafeHandle. Обрагцение к исходному дескриптору происходит через метод 
DangerousGetHandle. 

НелБЗн не упомннутБ о классе CriticalHandle, также определенном в про- 
странстве имен System . Runtime . InteropServices. Он работает точно так же, 
как и SafeHandle, но не поддерживает подсчет ссбшок. В CriticalHandle и про- 
изводнбгх от него классах безопасностк принесена в жертву повБшгениго произво- 
дителвности (за счет отказа от счетчиков). Как и у SafeHandle, у CriticalHandle 
еств два производнвгх типа — CriticalHandleMinusOnelsInvalid и CriticalHand 
leZeroOrMinusOnelsInvalid. Так как Microsoft отдает предпочтение безопасности, 
а не производителБности системнг, в библиотеке классов нет типов, производ- 
нБгх от зтих двух классов. ИсполБзуите типбг, производнБге от CriticalHandle, 
толбко когда вБгсокаи производителБностБ необходима и оправдБгвает некоторое 
ослабление загцитБг. 


Типм, исполБзукпцие системнме ресурсм 

Итак, теперк вбг знаете, как определитБ производнБги от SafeHandle класс, 
инкапсулиругогции системнБпг ресурс. Даваите посмотрим, как разработчики 
исполБзугот подобнБге типбг. Начнем с более распространенного класса System . 
10. FileStream. Класс FileStream позволнет открвгтв фаил, прочитатБ из него 
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и записатћ в него баитБ 1 , а затем закрБ 1 ТБ его. При создании обвекта FileStneam 
ББ13Б1ваетсн Win32-^yHKuim CreateFile, возврагцаемБш дескриптор сохраннетсн 
в обвекте SafeFileHandle, а ссвшка на зтот обвект сохраннетсл как закрвгтое 
поле в обвекте FileStream. Класс FileStream также поддерживает рлд допол- 
нителвнБ 1 х CBOiicTB (например, Length, Position, CanRead) и методов (Read, 
Write, Flush). 

Допустим, нам требуетси код, которвпг создает временнвш фаил, записБшает 
в него баитБ 1 , после чего удаллет фаил. Длл начала рассмотрим такои вариант: 

using System; 
using System.IO; 

public static class Program { 
public static void Main() { 

// Создание баитов длл записи во временнни фаил 
Byte[] bytesToWrite = new Byte[] { 1, 2, 3, Л, 5 }; 

// Создание временного фаила 

FileStream fs = new FileStream("Temp.dat"j FileMode.Create); 

// ЗаписБ баитов во временнми фаил 
fs.Write(bytesToWrite, 0, bytesToWrite.Length) ; 

// Удаление временного фаила 

File.Delete("Temp.dat"); // Генерируетсл исклнзчение IOException 

} 

} 

К сожаленшо, если скомпоноватв и запуститБ зтот код, работатк он, скорее всего, 
не будет. Дело в том, что вб 130 в статического метода Delete обвекта File заставлнет 
Windows удалитв открБ 1 ТБ 1 и фаил, позтому метод Delete генерирует исклгочение 
System . 10. IOException с таким сообшением (процесс не может обратитксн к фаилу 
Temp.dat, потому что он исполБзуетсл другим процессом): 

The process cannot access the file "Temp.dat" because it is being used by 
another process 

Однако в некоторв 1 х случалх фаил все же удаллетсн! Если другои поток иници- 
ировал уборку мусора между вБ130вами методов Write и Delete, поле SafeFileHandle 
обвекта FileStream ввввшает свои метод финализации, которвш закрвшает фаил 
и разрешает вбшолнитбсл методу Delete. Однако вероитностк даннои ситуации 
краине мала, позтому в 99 случалх из 100 приведеннвпТ код работатк не будет. 

КлассБц позволнкнцие полвзователк) управлитв жизненнБш циклом инкапсу- 
лированшлх системнБ 1 х ресурсов, реализугот интерфеис IDisposable, которвп! 
вБшллдит так: 

public interface IDisposable { 
void Dispose(); 

} 
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ВНИМАНИЕ 

Если класс определлет поле типа, реализукнцего паттерн dispose, сам класс тоже 
должен реализоватв зтот паттерн. Метод Dispose должен уничтожатв обвект, на 
KOTopbin сснлаетсл поле. Зто позволит полвзователкз класса внзватв длл него Dis- 
pose, что в свокз очередв приведет косвобожденикз ресурсов, исполвзуемнхсамим 
обБектом. 


К счастгло, класс FileStneam реализует интерфеис IDisposable, а его реализа- 
цгш вћгзмвает Dispose длн приватного поли SafeFileHandle обвекта FileStneam. 
Tenepb Mbi можем изменита свои код так, чтобм фаил ивно закрмвалси в нужнми 
момент (вместо того, чтобм дожидатвси уборки мусора когда-нибудв в будугцем). 
Измененнми исходнми код вмглидит так: 

using System; 
using System.IO; 

public static class Pnogram { 
public static void Main() { 

// Создание баитов длл записи во временнми фаил 
Byte[] bytesToWrite = new Byte[] { 1, 2, 3, Л, 5 }; 

// Создание временного фаила 

FileStream fs = new FileStream("Temp.dat", FileMode.Create); 

// 3anncb баитов во временнни фаил 
fs.Write(bytesToWrite, 0, bytesToWrite.Length); 

// Ввное закрмтие фаила после записи 
fs.Dispose( ) ; 

// Удаление временного фаила 

File.Delete("Temp.dat"); // Tenepb зта инструкцил 

// всегда остаетсн работоспособнои 

} 

} 


Tenepb при вмзове метода Delete обвекта File Windows видит, что фаил не 
открмт, и успешно удаллет его. 

Учтите, что гарантированное освобождение системнмх ресурсов возможно и без 
вмзова Dispose. Рано или поздно оно все равно будет вмполнено; вмзов Dispose 
позволлет вам управлитв тем, когда зто произоидет. Кроме того, вмзов Dispose не 
удаллет управлнемми обвект из управлнемои кучи. Единственнми способ осво- 
божденин памнти в управлиемои куче — уборка мусора. Зто означает, что методм 
управлиемого обвекта могут вмзмватвсн даже после освобождешга всех системнмх 
ресурсов, которме им могли iiciio. ib.ioiiai boi. 

Следугогции код вмзмвает метод Wnite после закрмтгга фаила и пмтаетси до- 
nncaTb в фаил несколвко баитов. Разумеетсл, новме баитм записанм не будут, 
а при вмполнении кода второи вмзов метода Wnite вмдает исклгочение System. 
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ObjectDisposedException со следукнцим сообшением (нет доступа к закрмтому 
фаилу): 

message: Cannot access а closed file. 
using System; 
using System.IO; 

public static class Prognam { 
public static void Main() { 

// Создание баитов длл записи во временнми фаил 
Byte[] bytesToWnite = new Byte[] { 1, 2, ?>, 4, 5 }; 

// Создание временного фаила 

FileStneam fs = new FileStneam("Temp.dat"j FileMode.Cneate); 

// Записи баитов во временнии фаил 
fs.Wnite(bytesToWnite, 0, bytesToWnite.Length); 

// Ввное закрмтие фаила после записи 
fs.Dispose(); 

// Попитка записи в фаил после закрнтив 
fs.Wnite(bytesToWnitej 0, bytesToWnite. Length); // Исклкзчение 
ObjectDisposedException 

// Удаление временного фаила 
File.Delete("Temp.dat"); 

} 

} 

В данном случае содержимое памнти не повреждаетсн, так как областБ, вмделен- 
нан длн обвекта FileStneam, все eme сугцествует; просто после нвного освобожденнн 
обвект не может успешно вмполнитб свои методм. 

ВНИМАНИЕ 

Определлл собственнми тип, реализукиции интерфеис IDisposable, обчзателвно 
сделаите так, 4To6bi все методм и своиства в случае лвнои очистки обвекта генери- 
ровали исклкзчение System.ObjectDisposedException. При повторнмх вмзовахметодм 
Dispose никогда не должнв! BbiflaBaTb исклкзчение ObjectDisposedException — они 
должнн просто возврашати управление. 


ВНИМАНИЕ 

Настоптелвно рекомендукз в об 1 цем случае отказатисн от примененип методов 
Dispose. Уборидик мусора из CLR достаточно хорошо написан, и nycTb он делает 
свокз работу сам. Он определлет, когда обвект более недоступен коду приложенил, 
и толикотогдауничтожаетего. Вмзнвал метод Dispose, код приложенич фактически 
запвллет, что сам «знает», когда обвект становитсл ненужнмм приложеникз. Но за- 
частукз приложение не может достоверно судити об зтом. 
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Допустим, у вас есљ код, создакнции новв 1 и обЂект. Ссмлка на зтот обтзект переда- 
етсл другому методу, котории сохранлет ее в переменнои в некотором внутреннем 
поле (то ecTb в корне), но вв1змвакпции метод никогда об зтом не узнает. Конечно 
же, он может вмзнвањ метод Dispose, но если какои-то код попитаетсл обратитвсл 
к зтому обиекту, будет вмдано исклкзчение ObjectDisposedException. рекомендукз 
Bbi3bmaTb MeTOflbi Dispose тол^ко там, где можно точно сказањ, что потребуетсл 
очистка ресурса (как в случае с попи 1 ткои удаленил открмтого фаила). 

Кроме того, несколико потоков могут одновременно вмзвањ Dispose длл одного 
обЂекта. В рекомендацилх проектированил указано, что метод Dispose не облзан 
6biTb 6e3onacHbiM по отношеник) к потокам. Дело в том, что код должен Bbi3biBaTb 
Dispose тол^ко в том случае, если он твердо уверен, что обтзект не исполизуетсл 
другими потоками. 


Приведеннме примерм кода демонстриругот методику нвного вмзова метода 
Dispose. Если вм решили восполвзоватБСн нвнбш вбгзовом, настолтелБно рекомен- 
дуго поместитБ его в блок обработки исклгочении f inally, так как зто гарантирует 
исполнение кода очистки. Соответственно код из предвгдугцего примера лучше 
переписатБ так: 

using System; 
using System.IO; 

public static class Program { 
public static void Main() { 

// Создание баитов длл записи во временнии фаил 
Byte[] bytesToWrite = new Byte[] { 1, 2, 3, 4, 5 }; 

// Создание временного фаила 

FileStream fs = new FileStream("Temp.dat", FileMode.Create); 
try { 

// ЗаписБ баитов во временнни фаил 
fs.Write(bytesToWrite, 0, bytesToWrite.Length); 

} 

finally { 

// Нвное закрнтие фаила после записи 
if (fs != null) 
fs.Dispose(); 

} 

// Удаление временного фаила 
File.Delete("Temp.dat"); 

} 

} 

ЗдесБ хорошо 6бшо 6 б 1 добавитБ код длн обработки исклгочении — не поленитесБ 
зто сделатБ. К счастБГО, в C# еств инструкцин using, предлагагогцаи упрогценнБпг 
синтаксис генерации кода, идентичного показанному. Вот как можно переписатБ 
предБвдугции код с помогцбго зтои инструкции: 
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using System; 
using System.IO; 

public static class Prognam { 
public static void Main() { 

// Создание баитов длл записи во временнми фаил 
Byte[] bytesToWrite = new Byte[] { 1, 2, 3, 4, 5 }; 

// Создание временного фаила 

using (FileStream fs = new FileStream("Temp.dat"j FileMode.Create)) { 

// Записи баитов во временнни фаил 
fs.Write(bytesToWritej 0, bytesToWrite.Length); 

} 

// Удаление временного фаила 
File.Delete("Temp.dat"); 

} 

} 

Инструкцин using инициализирует оођскт и сохраниет в переменнои ссмлку 
на него. После отого к отои переменнои можно обрагцатБСи из кода, расположен- 
ного в скобках в инструкции using. При компилнции отого кода автоматически 
создаготсл блоки try и f inally. ВнутрЂ блока f inally компиллтор помегцает код, 
вмполннгогции приведение типа обвекта к интерфеису IDisposable, и вмзмвает 
метод Dispose. Лсно, что компилитор позволиет исполБЗОватБ инструкциго using 
толбко с типами, в котормх реализован интерфеис IDisposable. 

ПРИМЕЧАНИЕ 

Инструкциа using R3biKa C# позволпет инициализироватв несколико переменних 
одного типа или исполизоватв переменнукз, инициализированнук) ранее. За допол- 
нителинои информациеи по зтои теме обраидаитесв к разделу «Using statements» 
в справочнике C# Programmer’s Reference. 


Интереснме аспектм зависимостеи 

Тип System. 10. FileStneam позволиет полБЗОвателго открмтБ фаил длн чтенгш 
и записи. Длл повмшенгш бмстродеиствии реализации типа задеиствует буфер 
в памнти. Содержимое буфера сбрасмваетсн в фаил толгжо после его заполненин. 
Тип FileStream поддерживает толђко записЂ баитов — дли записи символов или 
строк требуетси тип System . 10. StreamWriter, как показано в следугогцем примере: 

FileStream fs = new FileStreamCDataFile.dat", FileMode.Create); 

StreamWriter sw = new StreamWriter(fs); 
sw.Write("Hi there"); 

// Следугации вћвов метода Dispose обвзателен 
sw.Dispose(); 
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// ПРИМЕЧАНИЕ. Метод Streaml/Jriter . Dispose закрнвает обћект FileStream 
// Вручнут закрмвати обљект FileStream не нужно 

Обратите внимание: конструктор StreamWriter принимает в качестве параметра 
ссшлку на обвект Stream, тем самшм позволнн передатБ как параметр ссшлку на 
обвект FileStream. Внутреннии код обвекта StreamWriter сохраниет ссшлку на 
обвект Stream. При записи в обвект StreamWriter он вшполннет внутреннкно бу- 
феризацик) данншх в свои буфер в памнти. После заполненин буфера StreamWriter 
записшвает даннше в Stream. 

После записи данншх через обвект BinaryWriter следует вшзватБ метод Dispose 
(так как в типе StreamWriter реализован интерфеис IDisposable, его можно нсполб- 
зоватБ с инструкциеи using изкша С#). Вбиов заставлиет BinaryWriter сброситв 
даннБ1е в обвект Stream и закрвггБ его 1 . 

ПРИМЕЧАНИЕ 

Вручнук) Bbi3biBaTb метод Dispose длл обЂекта FileStream не облзателино: BinaryWriter 
сделает зто сам. Если же зтот метод все-таки вмзван лвно, FileStream обнаружит, что 
очистка обвекта уже внполнена, и визваннми метод просто вернет управление. 


Как вб 1 думаете, что 6 бшо 6бг, не будБ кода, нвно вБгзвшагогцего метод Dispose? 
Уборгцик мусора однаждкг правилБно определил 6 бг, что зти обвектБ 1 стали мусо- 
ром, и финализировал их. Но он не может гарантироватв определеннои очеред- 
ности вБгзова методов финализации. Позтому если обвект FileStream завершитсн 
первБгм, он закроет фаил. Затем после финализации обвекта StreamWriter он 
попБгтаетсл записатБ даннБге в закрвгтвш фаил, что ввгзовет исклгочение. В то же 
времи, если StreamWriter завершаетси перввш, даннБге благополучно записБша- 
готсл в фаил. 

Как с зтои проблемои справилисв в Microsoft? Заставитв уборгцик мусора 
финализироватБ обвектБг в определенном поридке нелвзи, так как обвектБг могут 
содержатБ ссбшки друг на друга, и тогда уборгцик не сможет определитБ правгшБ- 
нуго очередностБ их финализации. В Microsoft нашли вбгход: тип StreamWriter не 
поддерживает финализациго, позтому зтот тип не может сброситв даннБге из своего 
буфера в базоввш обвект FileStream. Таким образом, если вбг забБши вручнуго за- 
крвгтв обвект StreamWriter, даннБге гарантированно будут потеринБг В Microsoft 
считагот, что разработчики не смогут не заметитк зтои повторнгогцеисн потери 
даннБгх и исправит код, вставив пвнбпг вбгзов Dispose. 


1 Зто поведение можно переопределитћ вшзовом конструктора StreamWriter, получагошим 
логическии параметр leaveOpen. 
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ПРИМЕЧАНИЕ 

В .NET Framevvork подцерживакзтсп ynpaenneMbie расширенип отладки (Managed 
Debugging Assistants, MDA). Когда они BKmoneHbi, .NET Framevvork внполнлет поиск 
некоторнх распространенних ошибок в программах и запускает соответствунзидии 
отладчик. В отладчике все зто вмгллдит как генерирование исклкзченил. МПАуме- 
ет определпти ситуации, когда обт.ект StreamWriter удален убордиком мусора до 
своего закрнтип. 4To6bi вклнзчитб даннни управллемми отладчик в Visual Studio, 
откроите проект и Bbi6epnTe в менкз команду Debug ► Exceptions. В диалоговом 
окне Exceptions раскроите узел Managed Debugging Assistants, прокрутите стра- 
ницу вниз до злемента StreamWriterBufferedDataLost и установите флажок Throvvn, 
чтобм заставитв отладчикУЈзиа! Studio останавливатисл при каждои потере даннв 1 х 
обБекта StreamWriter. 


Другие возможности уборшика мусора длл работм 
с системнмми ресурсами 

Иногда системнми ресурс требует много памити, а управлиемБпТ обвект, ив- 
ллкнциисн его «оберткои», занимает оченв мало памити. Наиболее типичнбпТ 
пример — растровое изображение. Оно может заниматв несколБКО мегабаитов 
системнои памити, а управлиемвпТ обвект может 6 бдтб оченБ неболБшим, так как 
содержит толбко 4- или 8-баитовое значение. С точки зренил CLR до уборки 
мусора процесс может вБдделитБ сотни растровпдх изображении (которБде заимут 
мало управлнемои памити). Однако если процесс манипулирует множеством изо- 
бражении, расходование паммти процессом начнет расти с огромнои скоростБдо. 
Длн исправлении ситуации в классе GC предусмотренБ 1 два статических метода 
следугош,его вида: 

public static void AddMemoryPressure(Int64 bytesAllocated); 
public static void RemoveMemoryPressure(Int64 bytesAllocated); 

Зти методБг рекомендуетсл исполкзоватБ в классах, в которвгх задеиствованБг 
потенциалБно болншие системнБге ресурсБг, что6бг сообгцатБ уборгцику мусора о ре- 
алБном обЂеме заннтои памнти. Сам уборгцик следит за зтим показателем, и когда 
он становитсн болвшим, начинаетси уборка мусора. 

06ђсм некоторкгх системнБгх ресурсов ограничен. Ранвше в Windows разре- 
шалосБ создаватБ всего пнтб контекстов устроиства. Также ограничивалосв число 
фаилов, открвгваемБгх приложением. Опитб же, с точки зренил CLR, до уборки 
мусора процесс может вБгделитБ памнтБ дли сотен обЂектов (требугогцих мало памн- 
ти). Однако при количественном ограничении на применение машиннвгх ресурсов 
попБгтка задеиствоватБ их болБше, чем разрешено, обљпшо приводит к поивлениго 
исклгоченил. 

Дли таких ситуации в пространстве имен System . Runtime . InteropServices 
предусмотрен класс HandleCollector: 

public sealed class HandleCollector { 

public HandleCollector(String name, Int32 initialThreshold); 
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public HandleCollector( 

String name, Int32 initialThneshold л Int32 maximumThreshold); 
public void Add(); 
public void Remove(); 

public Int32 Count { get; } 
public Int32 InitialThreshold { get; } 
public Int32 MaximumThreshold { get; } 
public String Name { get; } 

} 

B классе, нвлнкжцемсн оберткои системного ресурса с количественнмм огра- 
ничением, следует исполБЗОватБ зкземплнр зтого класса дли передачи уборгцику 
мусора информации о том, сколбко реалкно задеиствовано зкземплиров зтого ре- 
сурса. Внутреннии код класса поддерживает счетчик заннтБ 1 х зкземплнров, и когда 
значение счетчика становитси болвшим, происходит уборка мусора. 

ПРИМЕЧАНИЕ 

Код методов GC.AddMemoryPressure и HandleCollector.Add вБ13Б1вает GC.Collect длл 
запускауборш,ика мусора до достиженил поколением 0 своего предела. 06бмно на- 
столтелБно не рекомендуетсл принудителБно вБ13Б1ватБуборидик мусора, потому что 
зто отрицателБно сказБ 1 ваетсл на производителБности приложенил. Однако вб130в 
зтихметодовв классахпризванобеспечитБдоступ приложенил кограниченномучислу 
системнБ 1 х ресурсов. Если системнБ 1 х ресурсов окажетсл недостаточно, произоидет 
сбои приложенил. Длл болБшинства приложении лучше работатБ медленнее, чем не 
работатБ вообиде. 


Следукзгции код иллкзстрирует исполБЗОвание и резулвтат работБд методов 
сжатил памити и класса HandleCollector: 

using System; 

using System.Runtime.InteropServices; 

public static class Program { 
public static void Main() { 

MemoryPressureDemo(0); // 0 вмзмвает нечастут уборку мусора 
MemoryPressureDemo(10 * 1024 * 1024); // 10 Мбаит внзмватт частут 

// уборку мусора 


HandleCollectorDemo( ); 

} 

private static void MemoryPressureDemo(Int32 size) { 
Console.WriteLine(); 

Console.WriteLine("MemoryPressureDemo, size={0}", size); 

// Создание набора обиектов c указанием их логического размера 
for (Int32 count = 0; count < 15; count++) { 
new BigNativeResource(size); 

} 


продолжение & 
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// В демонстрационнмх целнх очишаем все 
GC.Collect(); 

} 

private sealed class BigNativeResource { 
private Int32 m_size; 

public BigNativeResource(Int32 size) { 
m_size = size; 

// Пустц уборшик думает, что обцект занимает болнше памлти 
if (m_size > 0) GC.AddMemoryPressure(m_size); 

Console . WriteLine("BigNativeResource create."); 

} 

~BigNativeResource() { 

// Пустц уборшик думает, что обцект освободил болише памлти 
if (m_size > 0) GC . RemoveMemoryPressure(m_size); 

Console.WriteLine("BigNativeResource destroy."); 

} 

} 

private static void HandleCollectorDemo() { 

Console.WriteLine(); 

Console.WriteLine("HandleCollectorDemo"); 

for (Int32 count = 0; count < 10; count++) new LimitedResource(); 

// B демонстрационншх целлх очишаем все 
GC.Collect(); 

} 

private sealed class LimitedResource { 

// Создаем обцект HandleCollector и передаем ему указание 
// переити к очистке,когда в куче полвитсн два или более 
// обцекта LimitedResource 
private static HandleCollector s_hc = 

new HandleCollector("LimitedResource", 2); 

public LimitedResource() { 

// Сообшаем HandleCollector, что в кучу добавлен еше 
// один обцект LimitedResource 
s_hc.Add(); 

Console.WriteLine("LimitedResource create. Count={0}", s_hc.Count); 

} 

~LimitedResource() { 

// Сообшаем HandleCollector, что один обцект LimitedResource 
// удален из кучи 
s_hc . Remove() ; 

Console.WriteLine("LimitedResource destroy. Count={0}", s_hc.Count) 

} 

} 

} 
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После компилнции и запуска зтого кода резулкгат будет вмглздетБ примерно так: 

MemoryPressuneDemOj size=0 
BigNativeResource create. 

BigNativeResource create. 

BigNativeResource create. 

BigNativeResource create. 

BigNativeResource create. 

BigNativeResource create. 

BigNativeResource create. 

BigNativeResource create. 

BigNativeResource create. 

BigNativeResource create. 

BigNativeResource create. 

BigNativeResource create. 

BigNativeResource create. 

BigNativeResource create. 

BigNativeResource create. 

BigNativeResource destroy. 

BigNativeResource destroy. 

BigNativeResource destroy. 

BigNativeResource destroy. 

BigNativeResource destroy. 

BigNativeResource destroy. 

BigNativeResource destroy. 

BigNativeResource destroy. 

BigNativeResource destroy. 

BigNativeResource destroy. 

BigNativeResource destroy. 

BigNativeResource destroy. 

BigNativeResource destroy. 

BigNativeResource destroy. 

BigNativeResource destroy. 

MemoryPressureDemOj size=10485760 
BigNativeResource create. 

BigNativeResource create. 

BigNativeResource create. 

BigNativeResource create. 

BigNativeResource create. 

BigNativeResource create. 

BigNativeResource create. 

BigNativeResource create. 

BigNativeResource destroy 
BigNativeResource destroy 
BigNativeResource destroy 
BigNativeResource destroy 
BigNativeResource destroy 
BigNativeResource create. 

BigNativeResource create. 

BigNativeResource destroy 
BigNativeResource destroy 


продолжение # 
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BigNativeResource 

BigNativeResource 

BigNativeResource 

BigNativeResource 

BigNativeResource 

BigNativeResource 

BigNativeResource 

BigNativeResource 

BigNativeResource 

BigNativeResource 

BigNativeResource 

BigNativeResource 

BigNativeResource 


destroy. 
destroy. 
create. 
create. 
create. 
destroy. 
destroy. 
create. 
create. 
destroy. 
destroy. 
destroy. 
destroy. 


HandleCollectorDemo 
LimitedResource create. 
LimitedResource create. 
LimitedResource create. 
LimitedResource destroy. 
LimitedResource destroy. 
LimitedResource destroy. 
LimitedResource create. 
LimitedResource create. 
LimitedResource destroy. 
LimitedResource create. 
LimitedResource create. 
LimitedResource destroy. 
LimitedResource destroy. 
LimitedResource destroy. 
LimitedResource create. 
LimitedResource create. 
LimitedResource destroy. 
LimitedResource create. 
LimitedResource destroy. 
LimitedResource destroy. 


Count=l 

Count=2 

Count=3 

Count=3 

Count=2 

Count=l 

Count=l 

Count=2 

Count=2 

Count=2 

Count=3 

Count=3 

Count=2 

Count=l 

Count=l 

Count=2 

Count=2 

Count=2 

Count=l 

Count=0 


Внутреннлл реализацин финализации 

На первми взгллд, в финализации нет ничего особенного. Вм создаете обвект, а когда 
его подбирает уборгцик мусора, вмзмваетсл метод финализации зтого обвекта. Но 
на самом деле все гораздо сложнее. 

Когда приложение создает новми обвект, оператор new вмделлет длн него памнтБ 
из кучи. Если в типе обвекта определен метод финализации, непосредственно перед 
вмзовом конструктора зкземплнра типа указателБ на обвект помегцаетсл в список 
финализации (finalization list) — внутреннкно структуру даннмх, находлгцугосн под 
управлением уборгцика мусора. Каждан записБ зтого списка указмвает на обвект, 
длн которого нужно вмзватБ метод финализации, прежде чем освободитБ занлтуго 


им памнтБ. 
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На рис. 21.13 показана куча с несколБКими обЂектами. Одни достижимм из 
корнеи приложенин, другие — нет. При создании обкектов С, Е, F, / и/ система, 
обнаружив в их типах методм финализации, добавила указатели на зти обвектм 
в список финализации. 



Список финапизации Очередн на финализации 


Рис. 21.13. Управллемал куча с указателлми в списке финализации 


ПРИМЕЧАНИЕ 

Хотл в System.Object определен метод финализации, CLR его игнорирует. То ecTb 
если при создании зкземпллра типа метод финализации зтого типа унаследован от 
System.Object, созданнми обвект не считаетсл подлежаицим финализации. Метод 
финализации обЂекта Object должен переопределлтисл в одном из производнмхтипов. 

Сначала уборшик мусора определлет, что обвектм В,Е, G,H,I и Ј — зто мусор. 
Уборгцик сканирует список финализации в поисках указателеи на зти обвектм. 
Обнаружив указателЂ, он извлекает его из списка финализации и добавлнет в конец 
очереди на финализацгт (freachable queue) — епде однои внутреннеи структурм 
даннмх уборгцика мусора. Каждми указателЂ в зтои очереди идентифицирует о6ђ- 
ект, готовми к вмзову своего метода финализации. Вид управлиемои кучи после 
уборки мусора показан на рис. 21.14. 

На рисунке видно, что занитаи обвектами В, G и // памнтв бмла освобождена, 
посколвку у них нет метода финализации. Однако памитн, заннтуго обнектами Е, I 
и Ј, освободитЂ нелЂЗи, так как их методм финализации егце не вмзмвалисЂ. 

В CLR естЂ особми вмсокоприоритетнми поток, вмделеннми дли вмзова методов 
финализации. Он нужен длл предотврагценгш возможнмх проблем синхронизации, 
которме могли бм возникнутв при исполЂЗОвании вместо него одного из потоков 
приложенгш с обмчнмм приоритетом. При пустои очереди на финализациго (зто ее 
обмчное состонние) даннми поток бездеиствует. Но как толђко в неи поивлиготси 
злементм, он активизируетсл и последователвно удаллет злементм из очереди, 
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вмзмвал соответствукнцие методм финализации. Особенности работм данного 
потока запрегцагот исполннтб в методе финализации лгобои код, имегогции какие- 
либо допугценгш о потоке, исполнпгогцем код. Например, в методе финализации 
следует избегатБ обрагценип к локалБнои памити потока. 



Список финализации Onepeflb на финализацив 

Рис. 21.14. Управлчемаи куча с указателами, перемеиценнв 1 ми изсписка 
финализации в очередц на финализацик) 

Возможно, в будугцем, CLR будет поддерживатБ множественнме потоки фина- 
лизации, позтому следует избегатБ созданин кода, в котором методн финализации 
вмзмваготсл последователБно. При наличии всего лишг> одного потока фггнали- 
зации могут вознггкнутБ проблемм производителБности и масштабируемости 
в ситуации, когда финализируемћге обвектБг распределнготсн между несколБКими 
процессорами, но лишб один поток исполниет методпг фггнализации — он может 
просто не успетБ. 

Взаимодеиствие списка финализации и очереди на финализациго само по себе 
замечателвно, но сначала и расскажу, почему зта очередп получила свое оригиналБное 
названгге. Очевидно, буква «f» означает «finalization», то еств «фггнализацгш»: каждан 
записБ в очереди — зто ссвглка на обвект в управлиемои куче, длл которого должен 
6бгтб вБгзван метод финализации. Втораи частв оригиналБного имени, «reachable», 
означает, что зти обвектБг доступнБг. То естБ ее можно 6бгло 6бг назватБ очередБго 
ссбглок на обвектБг, доступнБге длл финализации, но дли краткости мбг будем назБг- 
ватБ ее очередБго на финализациго. Зту очередБ можно рассматриватБ и просто как 
коренБ, подобно статическим полим, которпге ивлиготси корннми. Таким образом, 
находигциисн в очереди на финализациго обвект доступен и не пвлнетси мусором. 

Короче говорп, если обвект недоступен, уборгцик считает его мусором. Далее, 
когда уборгцик перемегцает ссвглку на обвект из списка финализации в очередв на 
фггнализациго, обвект перестает считатпсн мусором, а зто означает, что заннтуго 
им памнтБ освобождатБ нелБЗи. На зтом зтапе уборгцик завершает поиск мусора, 
и некоторвге обвектБг, идентифицированнБге как мусор, перестагот считатпсн тако- 
вбгм — онгг как 6бг воскрестот. 
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По мере маркировки обвектов из очереди другие обвектм, на которме ссмлаготса 
их полн ссмлочного типа, также рекурсивно помечаготсн — все зти обвектм должнм 
пережитБ уборку мусора. На зтои стадии уборгцик мусора завершил вћшвление 
мусора, а некоторћге обт.сктр. 1 , отнесеннБге к мусору, 6бши воскрешенБк Уборгцик 
мусора сжимает освобожденнуго памитБ, воскрешеннвге обвектБг переводлтси 
в более старое поколение, а особћги поток CLR очигцает очередБ на финализациго, 
вбгполнин метод финализации длл каждого обвекта из очереди. 

ВБгзваннвги снова, уборгцггк обнаруживает, что фггнализированнБге обвектБг сталгг 
мусором, так как нгг корни приложентш, нгг очередн на финализациго болнше на них 
не указБгвагот. Памнтв, занитаи зтггми обвектами, попросту освобождаетсл. Важно 
поннтб, что длн освобожденгш памнти, заннтои обвектами, требугогцими финализа- 
ции, уборку мусора нужно вбгполнитб дваждБг. На самом деле может понадобитБСн 
и болБше операции уборкгг мусора, посколнку обвектБг переходлт в следугогцее по- 
коление (но об зтом — чутв позже). На рис. 21.15 показан вид управлиемои кучи 
после второи уборки мусора. 



' / 
> / 
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Список финализации Onepeflb на финализацик) 

Рис. 21.15. Состоание управлаемои кучи после второиуборки мусора 


Мониторинг и KOHTpo/ib времени 
жизни обтзектов 

Дли каждого домена приложенин CLR поддерживает таблицу GC -дескрипторов 
( GC handle table ), с помогцбго которои прггложенгге отслежггвает времн жггзнгг обвекта 
илгг позволнет управллтв ггм вручнуго. В момент создангш домена прггложенгш таблгг- 
ца пуста. Каждвги злемент таблицнг состоггт ггз указателн на обвект в управлиемои 
куче и флага, задагогцего способ мониторинга или контроли обвекта. Прггложение 
добавлиет в таблицу и удалнет из таблицвг злементБг с помогцбго показанного далее 
тггпа System . Runtime . InteropServices.GCHandle. 
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// Тип определлетсл в пространстве имен System.Runtime.InteropServices 
public struct GCHandle { 

// Статические методн, создаклцие злементм таблицн 
public static GCHandle Alloc(object value); 

public static GCHandle Alloc(object value, GCHandleType type); 

// Статические методн, преобразукицие GCHandle в IntPtr 
public static explicit operator IntPtr(GCHandle value); 
public static IntPtr ToIntPtr(GCHandle value); 

// Статические методн, преобразукицие IntPtr в GCHandle 
public static explicit operator GCHandle(IntPtr value); 
public static GCHandle FromIntPtr(IntPtr value); 

// Статические методш, сравниваккцие два типа GCHandles 
public static Boolean operator ==(GCHandle a, GCHandle b); 
public static Boolean operator !=(GCHandle a, GCHandle b); 

// Зкземпллрнми метод, освобождакхции злемент таблицш (индекс равен 0) 
public void Free(); 

// Зкземпллрное своиство, извлекакицее/назначакицее 
// длл злемента ссмлку на обцект 
public object Target { get; set; } 

// Зкземпллрное своиство, равное true при отличном от 0 индексе 
public Boolean IsAllocated { get; } 

// Длл злементов с флагом pinned возврашаетсл адрес обцекта 
public IntPtr AddrOfPinnedObject( ); 

public override Int32 GetHashCode(); 
public override Boolean Equals(object o); 

} 


B сушности, длн контролн или мониторинга времени жизни обнекта вмзмваетсн 
статическии метод Alloc обвекта GCHandle, передаклции ссмлку на зтот обвект, и тип 
GCHandleType, которми представллет собои флаг, задаклции способ мониторинга/ 
контроли обвекта. Перечислимми тип GCHandleType определлетсн так: 

public enum GCHandleType { 

Weak = 0, // Мониторинг сушествованив обцекта 

WeakTrackResurrection = 1 // Мониторинг сушествованив обцекта 
Normal = 2, // Управление временем жизни обцекта 

Pinned =3 // Управление временем жизни обкекта 

} 

Вот что означагот зти флаги. 

□ Weak — мониторинг времени жизни обвекта. Флаг позволлет узнатБ, когда 
уборгцик мусора обнаруживает, что обвект более недоступен коду приложенин. 
Учтите, что метод финализации обвекта мог как вмполнитбси, так и не вмпол- 
нитбси, позтому обвект может по-прежнему оставатБСи в памлти. 
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□ WeakTrackResurrection — мониторинг времени жизни обЂекта. Флаг позволнет 
узнатЂ, когда уборгцик мусора обнаруживает, что обнект более недоступен коду 
приложенин. Учтите, что метод финализации обнекта (если таковои имеетсл) 
уже точно бмл вмполнен, то естБ памнтБ, занитал обнектом, бнша освобождена. 

□ Normal — контролв времени жизни обнекта. Флаг заставллет уборгцик мусора 
оставитв обЂект в памнти, даже если в приложении нет переменнБ 1 х (корнеи), 
ссвшагошихсл на него. В ходе уборки мусора памитБ, занитан зтим обЂек- 
том, может 6 б 1 тб сжата (перемегцена). Метод Alloc, не принимагогции флаг 
GCHandleType, предполагает, что задано значение GCHandleType . Normal. 

□ Pinned — контролБ времени жизни обнекта. Флаг заставллет уборгцик мусора 
оставитБ обЂект в памнти, даже если в приложенгш нет переменнвгх (корнеи), 
ссБшагогцихсл не него. В ходе уборки мусора памнтБ, заннтан зтим обнектом, 
не может 6бгтб сжата (перемегцена). Зто обнгчно бншает полезно, когда нужно 
передатБ адрес памлти в неуправлнемвш код. НеуправлиемБги код может вбг- 
полннтб записБ по зтому адресу в управлнемои куче, знан, что расположение 
управлиемого обнекта после уборки мусора не изменитсн. 

При вБгзове статическии метод Alloc обкекта GCHandle сканирует таблицу GC- 
дескрипторов домена приложенгш в поисках злемента, в котором хранитсн адрес 
обвекта, переданного ему в качестве параметра. При зтом устанавливаетсл флаг, 
переданнБпг в качестве параметратипу GCHandleType. Затем метод Alloc возврагцает 
зкземплнр GCHandle. Тип GCHandle — зто «облегченнБпг» значимБш тип, содержа- 
гции одно зкземплнрное поле IntPtn, ссБшагогцеесл на индекс злемента в таблице. 
Чтобвг освободитБ зтот злемент в таблице GC -дескрипторов, нужно взнтб зкзем- 
плнр GCHandle и вБгзватБ метод Free (которБш также обБнвлнет недеиствителвнБш 
зкземплнр, обнулнн поле IntPtr). 

Вот как уборгцик мусора работает с таблицеи GC -дескрипторов. 

1. Уборгцик мусора маркирует все доступнвге обЂектБ 1 (как описано в начале зтои 
главвг). Затем он сканирует таблицу GC -дескрипторов, все обЂектвг с флагом 
Normal гши Pinned считаготсл корннми и также маркируготси (в том числе все 
обнектБг, на которнге они ссБшаготсн через свои поли). 

2. Уборгцик мусора сканирует таблицу GC -дескрипторов в поисках всех записеи 
с флагом Weak. Если такаи записв ссБшаетсн на немаркированнБш обЂект, ука- 
зателБ относитсл к недоступному обнекту (мусору) и приравниваетси к null. 

3. Уборгцик мусора сканирует список финализацгш. Если указателв из списка 
ссБшаетси на немаркированнБш обЂект, зтот обкект начинает считатнсн недо- 
ступнБш и перемегцаетсн из списка финализацгш в очередв на финализациго. 
В зтот момент обнект маркируетсл, потому что начинает считатнси доступнБш. 

4. Уборгцик мусора сканирует таблицу GC -дескргшторов в поисках всех злементов 
с флагом WeakTrackResurrection. Если такои злемент ссвшаетсл на немарки- 
рованнБш обБект (теперБ зто обЂект, на которнш указБгвает злемент из очереди 
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на финализацшо), указателћ считаетсл относнтцимсн к недоступному обЂекту 
(мусором) и приравниваетсл к null. 

5. Уборвдик мусора сжимает памнтБ, убиран свободнћш места, оставшиесн на месте 
недоступнБ 1 х обвектов. Учтите, что убортцик иногда предпочитает не сжиматБ 
памнтБ, если посчитает, что фрагментации низка и на ее устранение не стоит 
тратитБ времн. ОбЂектБ 1 с флагом Pinned не сжимаготсл (не перемегцаготсл), 
а обБектБг, находлгциесл рндом, могут перемегцатБСн. 

РазобравшисБ в логике работвг уборгцика, попробуем исполБЗОватБ зти знанин 
на практике. Наиболее поннтнбг флаги Normal и Pinned, позтому начнем с нггх. 
06бгчно онгг применнготсн при взаимодеиствии с неуправлиемвгм кодом. 

Флаг Normal исполБзуетсн дла передачи ссбглки на управлиемБги обвект не- 
управлнемому коду при условии, что позже неуправлнемБш код вбгполнит обратнБги 
вбгзов управлнемого кода, передав ему зту ссБглку. В обгцем случае невозможно 
передатв ссбглку на управлиемБги обвект неуправлиемому коду, потому что при 
уборке мусора адрес обвекта в памнти может изменитвси, и указателв станет не- 
деиствителБНБгм. Что6бг решитБ зту проблему, можно вБгзватБ метод Alloc обвекта 
GCHandle и передатБ ему ссБглку на обвект и флаг Normal. Затем возврагценнБш 
зкземплнр GCHandle нужно привести к типу IntPtr и передатв полученнБги ре- 
зулБтат в неуправлнемБш код. Когда неуправлнемБш код вбгполнит обратнБги 
вбгзов управлиемого кода, последнии приведет передаваемвги тип IntPtr обратно 
к GCHandle, после чего запросит своиство Target, чтобвг получитв ссБглку на управ- 
лиемвги обвект (или его текугции адрес). Когда неуправлиемому коду зта ссвглка 
будет болБше не нужна, следует вБгзБгватБ метод Free обвекта GCHandle, которБги 
позволит очиститб обвект при следугогцеи уборке мусора (при условии, что длн 
зтого обвекта нет других корнеи). 

Обратите внимание, что в зтои ситуацгги неуправлнемвги код не работает с управ- 
лнемБгм обвектом как таковкгм, а лишб исполБзует возможностб сослатБСн на него. 
Однако бБгвагот ситуации, когда неуправлнемому коду требуетсл управлнемБги о6б- 
ект. Тогда зтот обвект следует отметитБ флагом Pinned — зто запретит уборгцику 
мусора перемегцатБ и сжиматБ его. Типичнбги пример — передача управлиемого 
обвекта String функции Win32. При зтом обвект String надо обизателвно отме- 
титб флагом Pinned, потому что нелБЗи передатБ ссбглку на управлнемБги обвект 
неуправлиемому коду из-за возможного перемегценгш зтого обвекта уборгциком 
мусора. В противном случае, если 6бг обвект String 6бгл перемегцен, неуправлие- 
мбги код вбгполннл 6бг чтение из памнти или записБ в памнтв, более не содержагцуго 
символов обвекта String, и работа приложенгш стала 6бг непредсказуемои. 

Пргг исполБЗОвании длн ввгзова метода механизма P/Invoke CLR автоматически 
устанавливает длн аргументов флаг Pinned и сбрасвгвает его, когда неуправлнемБш 
метод возврагцает управление. Позтому чагце всего в типе GCHandle не приходитсн 
самостолтелвно ивно устанавливатв флаг Pinned длл каких-либо управлиемБгх 
обЂектов. Тип GCHandle нужно нвно исполвзоватБ длл передачи адреса управли- 
емого обвекта неуправлиемому коду. Затем неуправлиемал функцгш возврагцает 
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управление, а неуправлиемому коду зтот обвект может потребоватБСн позднее. 
Чаше всего такал ситуацгм возникает при асинхроннмх операциих ввода-вмвода. 

Допустим, вм вмделнете памнтБ длн баитового массива, которми должен запол- 
нитБСн даннмми по мере их поступленин из сокета. Затем вмзмваетси метод Alloc 
типа GCHandle, передагогции ссмлку на массив и флаг Pinned. Далее при помогци 
возврагценного зкземплира GCHandle вмзмваетсл метод AddrOfPinnedObject. Он 
возврагцает IntPtr — деиствителБнми адрес обЂекта с флагом Pinned в управлнемои 
куче. Затем зтот адрес передаетсл неуправлнемои функции, которан сразу передает 
управление управлнемому коду. В процессе поступленгш даннмх из сокета буфер 
баитового массива не должен перемегцатБСн в памнти, что и обеспечиваетсн флагом 
Pinned. По завершении операции асинхронного ввода-вБшода вБгзБшаетсл метод 
Free обвекта GCHandle, которБги разрешает перемегценгш в буфер при следугогцеи 
уборке мусора. В управлнемом коде по-прежнему должна присутствоватБ ссБшка 
на зтот буфер, обеспечиван разработчику доступ к даннБгм. Зта ссБшка не позволит 
уборгцику полностбго убратБ буфер из памлти. 

Следует упоминутБ и о таком средстве фиксации обвектов внутри кода, как 
инструкцгш f ixed изБгка С#. Вот пример ее примененгш: 

unsafe public static void Go() { 

// Ввделение места под обБекти, которме немедленно преврашанЈтсл в мусор 
for (Int32 х = 0; х < 10000; х++) new Object(); 

IntPtr originalMemoryAddress; 

Byte[] bytes = new Byte[1000]; // Располагаем атот массив 

// после MycopHbix обБектов 

// Получаем адрес в памлти массива Byte[] 

fixed (Byte* pbytes = bytes) { originalMemoryAddress = (IntPtr) pbytes; } 

// Принудителннал уборка мусора 

// Мусор исчезает, позволлл сжати массив Byte[] 

GC.Collect(); 

// Повторное получение адреса массива Byte[] в памлти 
// и сравнение двух адресов 
fixed (Byte* pbytes = bytes) { 

Console.WriteLine("The Byte[] did{0} move during the GC", 

(originalMemoryAddress == (IntPtr) pbytes) ? " not" : null); 

> 

} 

Инструкцгш f ixed нзБгка C# работает зффективнеи, чем вБгделение в памити 
фиксированного GC -дескриптора. В данном случае она заставллет установитБ 
специалБНБш «блокиругогции» флаг на локалБнуго переменнуго pbytes. Уборгцик 
мусора, исследул содержимое зтого корнн и обнаруживаи отличнБге от null значе- 
нгш, понимает, что во времн сжатил перемегцатБ обвект, на которБш ссБшаетси зта 
переменнаи, нелБЗи. Компилитор C# создает IL -код, присваивагогции локалБнои 
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переменнои pbytes адрес обнекта из начала блока f ixed. При достижении конца 
блока компилнтор создает IL -инструкцшо, возврашагошуго переменнои pbytes 
значение null. Она перестает ссмлатБСи на обвект, позволии удалитБ зтот обвект 
в ходе следуклцеи уборки мусора. 

Флаги Weak и WeakTrackResurrection могут применнтБСн как в сценари- 
лх взаимодеиствил с неуправлиемвш кодом, так и при исполБЗОвании толбко 
управлиемого кода. Флаг Weak указБгвает, что обвект уже помечен как мусор, 
но занимаемаи им памнтБ пока может оказатнсл невостребованнои. А вот флаг 
WeakTrackResurrection указвшает на необходимостн возврагценгш памнти. В то 
времн как флаг Weak применнетсн повсеместно, н егце ни разу не видел примененгш 
^naraWeakTrackResurrection в реалвнБгх приложенгшх. 

Предположим, что обвект А периодически вБгзБшает метод длн обвекта В. Но на- 
личие ССБ1ЛКИ на обвект В со сторонкг обвекта А загцигцает его от уборгцика мусора, 
и вполне возможнБг ситуации, в которвгх такое поведение нежелателвно. Предпо- 
ложим, что вместо зтого нам нужно, чтобвг обвект А вБгзвшал метод обвекта В при 
условии, что последнии находитсл в управлнемои куче. Длн решенгш зтои задачи 
обвекту А следует ввгзватБ метод Alloc класса GCHandle, передав зтому методу ссбш- 
ку на обвект В и флаг Weak. В резулнтате в обвекте А будет хранитвсн возврагценнаи 
ссвшка на зкземплнр GCHandle, а не реалкнан ссншка на обвект В. 

Прн отсутствни других корнеи, сохраннгогцих обвект В, теперв он может отправ- 
лнтбсн в мусорнуго корзину. Если обвекту А понадобитсн ввгзватБ метод обвекта В, он 
обратитсн к предназначенному толбко длн чтенгш своиству Target класса GCHandle. 
Возврагцение зтим своиством значенгш, отличного от null, указвшает, что обвект В 
егце сугцествует. После зтого код обвекта А сможет привести возврагценнуго ссвшку 
к типу обп>скта В и вкгзватБ метод. Если же своиство Target возврагцает значение 
null, значит, oo'bcicr В уничтожен уборгциком мусора, и оођскт А не будет пБгтатвсн 
ББгзватБ метод обвекта В. Впрочем, код обвекта А может вкгзватБ метод Free типа 
GCHandle, что 6 б 1 разорватБ свнзб с зкземплнром GCHandle. 

ПосколБку из-за вбгсоких требовании к безопасности при фиксации или сохра- 
нении обЂСкта в памнти работатв с типом GCHandle не просто, в пространство имен 
System 6 бш вклгочен вспомогателвнБпг класс WeakReference: 

public sealed class WeakReference<T> : ISerializable where T : class { 
public WeakReference(T target); 

public WeakReference(T target, Boolean trackResurrection); 

public void SetTarget(T target); 

public Boolean TryGetTarget(out T target); 

} 

Зто не более чем обт>ектно-ориентированнан обертка длн зкземплнра 
GCHandle: конструктор зтого класса вБгзвшает метод Alloc класса GCHandle, 
его своиство TryGetTarget читает своиство Target класса GCHandle, метод 
SetTarget задает своиство Target класса GCHandle, а метод Finalize (ввгше не 
показан, посколкку лвллетсн загцшценнБш) — метод Free класса GCHandle. Длн 
работБг с классом WeakReference коду не требуетси специалБного разрешенгш, так 
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как зтот класс поддерживает толбко слабтле сснлки; поведение, предоставллемое 
зкземплнрами GCHandle, размеш;еннБ1ми в режимах Normal или Pinned, не под- 
держиваетсл. Недостатком класса WeakReference<T> лвлнетсл необходимоств 
пребБ1ванил обЂекта в куче. Из-зазтого обЂектБ1 WeakReference «веслт» болвше 
зкземпллров GCHandle. 

ВНИМАНИЕ 

ПознакомившисБ со слабими ссБшками, разработчики сразу же считакзт, что они 
хорошо подходлт длл кзшированил. Порлдок рассуждении примерно таков: «Хоро- 
шо 6bi создатБ много обвектов, содержаидих много даннБ 1 х, а затем создаљ длл них 
слабне ссбшки. Когда программе понадоблтсл зти даннБ 1 е, она с помошдкз слабои 
ссбшки проверит, естили поблизости обвект, содержаидии зти даннне, и обнаружив 
его рлдом, восполБзуетси нужнБ1ми данннми. Зто обеспечит BbicoKyio произво- 
flHTenbHOCTb». Однако после уборки мусора обЂектм, содержаидие flaHHbie, будут 
уничтоженм, и когда программе придетсл заново создавати flaHHbie, ее произво- 
дителвноств упадет. 

Недостатоктакого подхода втом, что уборка мусора не вмполнлетсл при переполнен- 
нои или почти переполненнои памлти. Напротив, она происходит, когда поколение 0 
заполнено. Позтому обЂектн удаллкзтсл из памлти гораздо чаиде, чем нужно, что 
значителвно снижает производителвности приложенил. 

Слабие ссмлки могут бмљ очени зффективнв 1 ми при кзшировании, но очени сложно 
создатвхорошии алгоритм кзшированил, обеспечивакдидии нужное равновесие между 
расходованием памлти и би 1 Стродеиствием. В суидности, необходимо, чтобн в кзше 
6bmn строгие сснлки на все обЂек™, а затем, когда памлти становитсл мало, строгие 
ссмлки должнм превраидатвсл в слабме. На сегоднлшнии момент CLR не поддер- 
живает механизм, позволлкзидии уведомллтв приложение об исчерпании ресурсов 
памнти. Тем не менее HeKOTopbie разработчики приспособилисБ периодически вм- 
3biBaTb )Мп32-функци10 GlobalMemoryStatusEx и проверл™ поле dwMemoryLoad воз- 
враиденнои структурн MEMORYSTATUSEX. Его значение, превмша 1 оидее 80, означает, 
что naMHTb на исходе и настало времл преобразовБ 1 ва™ строгие ссмлки в слаби 1 е 
по Bbi6paHHOMy алгоритму: по давности, частоте, времени исполвзованин обЂектов 
или по другим алгоритмам. 


Разработчикам часто требуетсл свчзатд фрагмент даннБгх с каким-нибудБ другим 
злементом. Например, можно свнзатБ даннБге с потоком или с доменом приложении. 
Класс System . Runtime . CompilerServices . ConditionalWeakTable<TKeyj TValue> 
позволлет свнзатБ даннБге с обЂектом. Вот как он вбгглнднт: 

public sealed class ConditionalWeakTable<TKeyj TValue> 
where ТКеу : class where TValue : class { 
public ConditionalWeakTable(); 
public void Add(TKey key, TValue value); 
public TValue GetValue( 

ТКеу key, CreateValueCallback<TKey, TValue> createValueCallback); 
public Boolean TryGetValue(TKey key, out TValue value); 
public TValue GetOrCreateValue(TKey key); 
public Boolean Remove(TKey key); 


продолжение & 
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public delegate TValue CreateValueCallback(TKey key); // Вложенное 

// определение делегата 

} 

Длн свизи произволБнмх даннмх с одним или несколБКими обвектами класса 
дли начала вам потребуетсл зкземплнр зтого класса. Затем следует вмзватБ метод 
Add, передав параметру key ссмлку на обвект, а параметру value — даннме, которме 
вм хотите свизатБ с зтим обЂектом. При по1њп ке повторного добавленгш ссбшки 
на тот же самБги обвект метод Add вБвдаст исклгочение ArgumentException. Что6бг 
изменитБ свнзанное с обвектом значение, нужно удалитв клгоч и добавитБ его снова 
уже с другим значением. Имеите в виду, что так как класс лвлнетсл безопаснБш 
в отношении потоков, его могут в конкурентном режиме исполБЗОватБ другие 
потоки, хотл зто не лучшим образом сказкшаетсл на производителБности. Произ- 
водителБностБ класса нужно проверитБ, что6бг узнатБ, насколБКО она достаточна 
именно длн вашего сценаргш. 

Разумеетсл, во внутреннеи реализации таблицБг хранитсн ссншка WeakRef erence 
на обвект, переданнБги им в качестве клгоча; зто гарантирует, что таблица не бу- 
дет принудителБно увеличиватБ времи жизни обвекта. Но особенноств класса 
ConditionalWeakT able состоит в том, что он гарантирует наличие в памнти значенин 
до тех пор, пока обвект идентифицируетсл в памнти по клгочу. Зто превосходит 
способности обвганого класса WeakReference, в котором значение уничтожаетсн 
уборгциком мусора, хотл клгоч егце сугцествует. Класс ConditionalWeakTable мо- 
жет применнтБСи длл реализации механизма своиств зависимости, исполвзуемого 
в XAML. Он может также внутренне исполБЗОватБСн в динамических нзвгках длн 
динамическои свнзи даншчх с обЂектами. 

Далее показан код, демонстриругогции применение класса ConditionalWeakTable. 
Он позволлет вБгзвшатБ метод расширенгш GCWatch дли лгобого обвекта, передаван 
в него некии тег String. В резулвтате при уничтожении обвекта в ходе уборки 
мусора вб 1 получаете извегцение через консолб: 

internal static class ConditionalWeakTableDemo { 
public static void Main() { 

Object o = new Object(),GCWatch("My Object created at " + DateTime.Now); 
GC.Collect(); // Оповешение об отправке в мусор не вмдаетсн 
GC.KeepAlive(o); // ОбБект, на которми ссмлаетсн о, должен сушествоватБ 
о = null; // ОбБект, на которми ссмлаетсн о, можно уничтожатБ 

GC.Collect(); // Оповешение об отправке в мусор 
Console.ReadLine(); 

} 

} 

internal static class GCWatcher { 

// ПРИМЕЧАНИЕ. Аккуратнее обрачаитесБ c типом String 

// из-за интернированин и обБектов-представителеи MarshalByRefObject 

private readonly static ConditionalWeakTable<Object, 

NotifyWhenGCd<String>> s_cwt = 

new ConditionalWeakTable<Object, NotifyWhenGCd<String>>(); 
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private sealed class NotifyWhenGCd<T> { 
private readonly T m_value; 

internal NotifyWhenGCd(T value) { m_value = value; } 

public override string ToStringO { return m_value.ToString(); } 

~NotifyWhenGCd() { Console.WriteLine("GC'd: " + m_value); } 

} 

public static T GCWatch<T>(this T @object, String tag) where T : class { 
s_cwt.Add(@object, new NotifyWhenGCd<String>(tag)); 
return @object; 

} 



Глава 22. Хостинг CLR и доменн 
приложении 


В зтои главе обсуждаготси две темм, позволигогцие по-настоигцему оценитБ до- 
стоинства Microsoft .NET Framework, — хостинг (hosting) и домени приложенип 
(AppDomains). Благодарн хостингу лгобое приложение может исполћзоватБ возмож- 
ности обгцензБпсовои средБ1 CLR, в частности сугцествугогцие приложенгш можно, 
по краинеи мере, частично, переписатв при помогци управлнемого кода. Кроме того, 
хостинг позволиет настраиватБ и дополннтб приложенгш на программном уровне. 

Поддержка дополнении означает возможностб вклгоченгш в свои программвг кода 
сторонних разработчиков. В Microsoft Windows загрузка чужих DLL -библиотек 
бвша исклгочителБно рискованнБгм меропргштием. В такои библиотеке оченк легко 
мог оказатБСи код, разрушагогции структуркг даннБгх, и код приложении. Кроме 
того, библиотека могла исполБЗОватБ контекст безопасности приложении длн 
полученгш доступа к ресурсам, к которнгм в обвшнБгх условгшх доступа у нее нет. 
Доменвг приложении позволили решитв зти проблемБг. Именно они дагот возмож- 
ностб запускатБ не полБзугогциисн доверием код сторонних разработчиков, а CLR 
гарантирует безопасноств и целостностБ структур даннкгх и кода, а также невоз- 
можностб исполБЗОватБ в неблаговиднБгх целих контекст безопасности. 

06бшно хостинг и доменБг приложении исполБзугот нариду с загрузкои сборок 
и отражением. Совместное применение зтих четвгрех технологии преврагцает CLR 
в невероитно богатуго и могцнуго платформу. Зта глава посвигцена в основном хо- 
стингу и доменам приложении, а о загрузке сборок и отраженгш рассказвшаетси 
в следугогцеи главе. Изучив и освоив зти технологии, вбг узнаете, почему усилин, 
затраченнБге на освоение .NET Framework, с лихвои окупнтсн в будугцем. 


Хостинг CLR 

Платформа .NET Framework работает поверх Microsoft Windows. Зто значит, что 
в ее основе должнбг лежатБ технологии, с которБши Windows может взаимодеи- 
ствоватв. Длн начала все фаилвг управлнемБгх модулеи и сборок должнбг иметБ 
формат РЕ (portable executable), нвлнтбсн исполннемБши фаилами Windows (ЕХЕ) 
или динамически подклгочаемБши библиотеками (DLL). 

В Microsoft разработали CLR в виде СОМ-сервера, содержагцегоси в DLL. То 
еств разработчики определили длл CLR стандартнБш СОМ-интерфеис и присвоили 
зтому интерфеису и СОМ-серверу глобалвно уникалБНБге идентификаторБ! (GUID). 
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При установке .NET Framework СОМ-сервер, представлнгшции CLR, регистрирует- 
сн в реестре Windows как лгобои другои СОМ-сервер. Подробнее см. заголовочнми 
фаил С++ MetaHost.h из .NET Framework SDK — в зтом фаиле определенм все 
GUID -идентификаторм и неуправлпемми интерфеис ICLRMetaHost. 

Лгобое Windows-npimo>KeHiie может статБ хостом (управлнгогцим приложением) 
длл CLR. Однако не следует создаватБ зкземплнрБ1 СОМ-сервера CLR функциеи 
CoCreatelnstance; вместо зтого неуправлиемБш хост должен вБИБшатБ функциго 
CLRCreatelnstance, обБнвленнуго в фаиле MetaHost.h. Зта функцгш реализована 
в библиотеке MSCorEE.dll, которал обвшно расположена в каталоге C:\Windows\ 
System32. Обвшно зту библиотеку назБшагот оболочкоп совместимости (shim) — она не 
содержит СОМ-сервер CLR, а толбко определнет, какуго версиго CLR следует создатв. 

На однои машине допускаетсл установка несколвких версии CLR, но может 
6 б 1 тб толбко одна версин фаила MSCorEE.dll (оболочка совместимости) 1 . Версин 
библиотеки MSCorEE.dll совпадает с версиеи самои последнеи установленнои сре- 
дб 1 CLR, позтому зта версин MSCorEE.dll <<знает», как наити лгобвге более ранние 
версии CLR, которвге устанавливалисБ на машине. 

Код CLR содержитсл в фаиле, ими которого зависит от версии. Длн версии 
1.0, 1.1 и 2.0 зто фаил MSCorWks.dll, а длн версии 4.0 — фаил Clr.dll. Так как на один 
компвготер можно установитн несколБКО версии CLR, зти фаилвг располагаготсл 
в разнвгх папках 2 : 

□ версгш 1.0 — в папке C:\Windows\Microsoft.NET\Framework\v1 .0.3705; 

□ версгш 1.1 — в папке C:\Windows\Microsoft.NET\Framework\v1 .0.4322; 

□ версгш 2.0 — в папке C:\Windows\Microsoft.NET\Framework\v2. 0.50727; 

□ версгш 4.0 — в папке C:\Windows\Microsoft.NET\Framework\v4. 0.21006. 

Функцил CLRCreatelnstance возврагцает интерфеис ICLRMetaHost. Хост- 
приложение может вБгзвшатБ функциго GetRuntime зтого интерфеиса, указншан 
ту версиго CLR, которуго следует создатв. После зтого оболочка совместимости 
загружает зту версиго в текугции процесс. 

По умолчаниго оболочка совместимости анализирует управлнемБпг исполннемБш 
фаил и извлекает из него сведенгш о версгш CLR, с которои бвшо построено и про- 
тестировано приложение. Однако приложение может переопределитв заданнБге 
по умолчаниго сведенгш, записав злементвг requiredRuntime и supportedRuntime 
в конфигурационнБш ХМЕ-фаил (см. главБ! 2 и 3). 


1 В 64-разрнднои версии Windows в деиствителвности установленш два варианта фаила 
MSCorEE.dll. Первни — зто 32-разрнднал версин х86, расположеннан в папке C:\Windows\ 
SysWOW64, второи — 64-разрнднал версил х64 или IA64 (в зависимости от архитектурм 
процессора), расположеннан в папке C:\Windows\System32. 

2 Обратите внимание, что версии .NET Framework 3.0 и 3.5 поставллготсл с CLR 2.0. Л не 
указмваго, в каких папках находнтсн версии .NET Framework 3.0 и 3.5, так как DLL -библиотека 
CLR загружаетсл из папки v2. 0.50727. 
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Функцил GetRuntime возвратцает указателБ на неуправлиемми интерфеис 
ICLRRuntimelnfo, из которого при помогци метода Getlnterface получаетсл ин- 
терфеис ICLRRuntimeHost. Вмзмваи методм зтого интерфеиса, хост-приложение 
может вмполннтб следугогцие операции: 

□ УстанавливатБ хост-диспетчерБ1 (host managers), то естБ сообтатБ CLR, что 
хост должен участвоватБ в решенгшх, свчзаннвгх с вБгделением памити, плани- 
рованием и синхронизациеи потоков, загрузкои сборок и т. п. Кроме того, хосту 
могут понадобитБСп уведомленгш о начале и окончании уборки мусора, а также 
о завершении определеннвгх операции. 

□ ПолучатБ информациго о CLR -диспетчерах, то естБ запрегцатБ CLR исполБЗОватБ 
определеннБге классБг или членБг Кроме того, хост может указатБ подлежагции 
и неподлежагции отладке код, а также методкг, вБгзБгваемБге при наступленгш 
определеннБгх со6бгтии, таких как вкггрузка домена приложенгш, остановка CLR 
или исклгочение, ввгзванное переполнением стека. 

□ ИнициализироватБ и запускатБ CLR. 

□ ЗагружатБ сборку и исполннтб ее код. 

□ ОстанавливатБ CLR, предотврагцан далвнеишее исполнение управлнемого кода 
в Windows-nponecce. 

Сугцествует много доводов в полвзу примененгш хостинга CLR. К примеру, 
он дает лгобому приложениго доступ к возможностпм CLR и программнвш сред- 
ствам, а также хотн 6 бг частично 6 бгтб написаннБш на управлпемом коде. Многие 
приложенгш, обеспечивагогцие хостинг исполнпгогцеи средвг, предлагагот массу 
возможностеи разработчикам, стремпгцимсл к расширениго функционалБности. 
Вот толбко некоторкге возможности: 

□ программирование на лгобом и.зшсе; 

□ код может компилироватБСи (а не интерпретироватБСн) JIT -компилнтором, что 
обеспечивает максималвное бБгстродеиствие; 

□ поддержка уборки мусора, предотврагцагогцеи утечки и повреждение памнти; 

□ вБшолнение кода в безопаснои изолицгш; 

□ хосту не нужно заботитвсн о предоставленгш многофункционалБнои среднг 
разработки, вместо зтого он исполвзует имегогциесн технологгш: пзбгки, компи- 
лпторБг, редакторБг, отладчики, средства профилировангш и пр. 

Тем, кто интересуетсл подробностнми хостинга CLR, н настолтелБно рекомендуго 
отличнуго книгу Стивена Претчнера (Steven Pratschner) «Customizing the Microsoft 
.NET Framework Common Language Runtime» (Microsoft Press, 2005), несмотрн на 
то, что в неи рассматриваготси более ранние, чем 4.0, версгш CLR. 
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ПРИМЕЧАНИЕ 

Конечно, Windows-npou,eccbi могут обоитиси и без CLR. Зта среда нужна толико длл 
исполненил в процессеуправллемого кода. До поивленил .NET Framework4.0 внутри 
Windows-npopecca допускалсл толвко один зкземпллр CLR. То ести процесс мог не 
содержат CLR вообше или же содержаљ какуко-нибуди из имеклдихсл версии — 1.0, 
1.1 или 2.0. Зто бмло сериезное ограничение. Например, в Microsoft Office Outlook 
6bmo невозможно загрузити два дополнителвнмх компонента, если они создавалиси 
и тестировалиси на разнмх версилх .NET Framework. 

К cnacTbio, начинал с .NET Framework 4.0, поддерживаетсл возможности загрузки 
версии 2.0 и 4.0 в один Windows-npopecc, позволлл компонентам, HanncaHHbiM длл 
.NET Framework 2.0 и 4.0, работаљ параллелБно, не испнтмвал проблем совмести- 
мости. Зта без преувеличенил фантастическал возможности позволлет применлти 
компонен™ .NET Framework в саммх разнмх сценарилх. Узнати, какал версил или 
версии CLR загруженм в определеннми процесс, можно с noMOu^bio утилитм ClrVer.exe. 

Загруженнукз в Windows-npopecc среду CLR вмгрузиљ уже нелизл. Методн AddRef 
и Release не влилкзт на интерфеис ICLRRuntimeFiost. Bbi можете толеко завершитБ 
процесс, вв 1 нудив Windows очистити все занлтме в нем ресурсм. 
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В ходе инициализации СОМ-сервер CLR создает домен приложенип (AppDomain), 
представликшдии собои логическии контеинер дли набора сборок. Первми из соз- 
даннмх доменов назмвагот основним (default AppDomain), он уничтожаетси толбко 
при завершении Windows-nponecca. 

Помимо основного, хост, исполБзуготии методм неуправлиемого СОМ- 
интерфеиса или методм управлнемого типа, может заставитБ CLR создатБ до- 
полнителБнме доменм приложении. Их основнои задачеи ивлнетсн обеспечение 
изолнции. Доменм приложении удобнм благодари несколћким своиствам. 

□ ОбЂектм, созданнме одним доменом приложении, недоступнм длн кода дру- 
гих доменов. Когда код домена приложении создает обвект, домен становитсн 
«хознином» зтого обЂекта. Иначе говорн, времн жизни обвекта ограничиваетси 
временем сугцествованин самого домена. Код другого домена может получитБ 
доступ к обвекту, толбко исполБзун семантику продвиженим no ссвшке (marshal- 
by-reference) или no значенит (marshal-by-value). Тем самнгм обеспечиваетси 
четкое разделение кода в домене приложении, так как код в одном домене не 
может напримуго ссБшатвсн на обвект, созданнБги в другом домене. Такаи изо- 
лнцин позволиет легко ввпружатБ доменБг приложении из процесса без влгшнин 
на работу других доменов. 

□ Доменм приложении можно вмгружатЂ. CLR не поддерживает ввггрузку от- 
делБНБгх сборок. Однако можно заставитк CLR вБггрузитБ домен приложении 
со всеми содержагцимиси в нем в даннвш момент сборками. 
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□ Доменм приложении можно индивидуалБно aamnmai h. При создании домену 
приложении можно назначитћ набор разрешении, определнкнции максималћнме 
права запушеннмх в нем сборок. Зто позволнет хосту загружатБ код и 6 мтб уве- 
реннмм, что зтот код не испортит или не прочитает важнме структурБ1 даншлх, 
исполБзуемБШ самим доменом. 

□ ДоменБ1 приложении можно индивидуалБно настраиватБ. Кдждбпг домен име- 
ет целБш набор конфигурационнБ 1 х параметров. Они в основном определигот, 
как среда CLR должна загружатБ сборки в домен. Сугцествугот и параметрБц 
относигциесн к путлм поиска, перенаправлениго привизки к версиим, теневому 
копированиго и оптимизации загрузчика. 

ВНИМАНИЕ 

Windows предоставлчетзамечателБну 10 возможностБзапускатБ каждое приложение 
всобственном адресном пространстве. Зто гарантирует, что кододного приложенич 
не получит доступа к коду и даннмм другого. Изолчцип процессов предотвраидает 
почвленич брешеи в системе безопасности, повреждение даннмх и другие непри- 
чтности, обеспечивал надежностБ Windows и работаклдих в зтои операционнои си- 
стеме приложении. К сожаленик), создание процесса в Windows — операцич оченБ 
ресурсоемкал. Win32-^yHK^M4 CreateProcess вмполнчетсл медпенно, а виртуализацич 
адресного пространства процесса требует много пампти. 

Однако если приложение полностбк) состоит из гарантированно безопасного 
управлпемого кода, которми ктому же не вмзБ 1 вает неуправллемми код, можно за- 
пуститБ несколБко управлчеммх приложении в одном Windows-npopecce. Их доменБ! 
обеспечат изолчцикз, необходимук) длп заш,итБ 1 , конфигурированил и завершенил 
отделБнмх приложении. 


На рис. 22.1 показан отделБНБш Wiri(lovvs-n|)Onccc, в котором работает один 
СОМ-сервер CLR, управлигогции двумл доменами приложенгш (кстати, не сугце- 
ствует жестких ограниченгш на количество доменов приложешш, которБге могут 
вбшолнитбсн в одном Windows-npouecce). У каждого такого домена еств собственнаи 
куча загрузчика, ведугцан учет обрагцении к типам с момента создании домена (зти 
типБг 6 бши подробно рассмотренБ 1 в главе 4). Каждому типу в куче загрузчика со- 
ответствует таблица методов, строки которои указвшагот на код метода (если зтот 
метод хотб раз исполннлсн, его код уже скомпилирован JIT -компилитором). 

Кроме того, в каждвш домен приложешш загруженБ 1 сборки. В первБш (он же 
основнои) загруженБ 1 три сборки: MyApp.exe, TypeLib.dll и System.dll, во второи — две 
сборки: Wintellect.dll и System.dll. 

Обратите внимание, что сборка System.dll загружаетсн в оба домена. Если в обоих 
доменах исполвзуетсн один тип из System.dll, в их кучах загрузчика будут размегценБ 1 
обЂектБг одинаковБ1х типов; памнтв, вБвделеннан под зти о6'бс ktbi, не исполБзуетсл 
доменами совместно. Более того, когда код домена вБгзвгвает определеннБШ в типе 
методвг, IL -код метода JIT -компилируетсн, а резулБтиругогции машиннБш код 
привизБгваетсн к каждому домену в отделвности, то естБ он не исполБзуетси ими 
совместно. 
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Windows-npouecc 


Домен приложении 1 (основнои) 


Куча загрузчика 


Туре1 


М1() 

(х86) 

М2() 

(х86) 


Туре2 


М1() 

(х86) 

М2() 

(х86) 




М1() 

(х86) 

М2() 

(х86) 



MyApp.exe 


TypeLib.dll 


System.dl I 




Исполнителнное лдро 

MSCorEE.dll (оболочка совместимости) —► Clr.dll (среда CLR) 

Рис. 22.1 . Windows-npouecc, авлакнцииса хостом длл CLR 
и двух доменов приложении 


Хотн отсутствие совместного исполБЗОвантш памнти дли храненин обвектов или 
машинного кода вб1глндит расточителБно, зто оправдано, посколћку доменБ1 прило- 
жении разрабатћшалисБ дли изолнции; у CLR должна 6б1тб возможностб вБшрузитБ 
домен приложении и освободитн все его ресурсБ 1 , никак не затронув осталБНБШ до- 
менБ1. Дублирование структур даннБ1х CLR обеспечивает зту возможностб. Кроме 
того, оно также гарантирует, что при исполБЗОвании разнвши доменами одного типа 
статические поли будут задаватнси отделБно дли каждого домена. 

I lcKO'iopbie сборки предназначенБ 1 длн совместного исполБЗОвангш разнвши до- 
менами. Лучшии пример — сборка MSCorLib.dll, созданнаи в Microsoft. Именно eii 
принадлежат тшш System .Object, System . Int32 и другие типб1, неотделимБге от 
.NET Framework. Зта сборка автоматически загружаетси при инициализации CLR, 
и доменБ1 приложении совместно исполвзутот ее типб1. Длл зкономии ресурсов 
MSCorLib.dll загружаетсл как сборка, не свизаннан с конкретнвш доменом. Обв- 
ектБ 1 всех типов в зтои куче загрузчика и весв машиннБш код методов зтих типов 
совместно исполБзуготсн всеми доменами процесса. К сожаленикз, длн достиженин 
всех преимугцеств от совместного исполвзовангш ресурсов приходитси кое-чем 
жертвоватв: сборки, загруженнБге без привнзки к доменам, нелвзн вБггружатБ до 
завершенгш процесса. Единственнвги способ вернутв ресурсБг — завершитБ про- 
цесс. 
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Доступ к обвектам из других доменов 

Код, расположеннми в одном домене приложении, способен взаимодеиствоватБ 
с типами и обвектами другого домена. Однако доступ к зтим типам и обвектам 
возможен толбко через тгцателБно определеннме механизмм. Приведеннми далее 
пример демонстрирует процедуру созданин домена приложении, загрузку в него 
сборки и конструирование определенного в зтои сборке зкземплнра типа. Код ил- 
лгострирует различное поведение при конструировании типа, передаваемого путем 
продвиженин по ссмлке и по значениго, а также типа, которми вообгце не исполБзует 
механизм продвиженгш. Кроме того, демонстрируетсл, как обЂектБц переданнБШ 
посредством разнвш вариантов продвиженгш, ведут себн при ввггрузке создавшего 
их домена приложении. В зтом примере мало кода, зато много комментариев. Затем 
следугот подробнБге обБнснешш, что именно делает CLR: 

private static void Marshalling() { 

// Получаем сшлку на домен, в котором исполнлетсл вивмвак) 1 ции поток 
AppDomain adCallingThreadDomain = Thread.GetDomain(); 

// Каждому домену присваиваетсл значимое имл, облегчатцее отладку 
// Получаем имл домена и вшводим его 

String callingDomainName = adCallingThreadDomain . FriendlyName; 

Console.WriteLine( 

"Default AppDomain's friendly name={0}", callingDomainName); 

// Получаем и вмводим сборку в домене, содержашем метод Main. 

String exeAssembly = Assembly.GetEntryAssembly().FullName; 

Console.WriteLine("Main assembly={0}", exeAssembly); 

// Определвем локалБнут переменнукц ссцшак)шук)сл на домен 
AppDomain ad2 = null; 

// ПРИМЕР 1. Доступ к обвектам другого домена приложении 
// с продвижением по сшлке 

Console.WriteLine("{0}Demo #1", Environment.NewLine); 

// Создаем новши домен (с теми же параметрами зашитт и конфигурированив) 
ad2 = AppDomain.CreateDomain("AD #2", null, null); 

MarshalByRefType mbrt = null; 

// Загружаем нашу сборку в новши домен, конструируем обБект 
// и продвигаем его обратно в наш домен 

// (в деиствителвности мш получаем сшлку на представителк.) 
mbrt = (MarshalByRefType) 

ad2.CreateInstanceAndUnwrap(exeAssembly, "MarshalByRefType"); 

Console.WriteLine("Type={0}", mbrt.GetType()); // CLR неверно 

// определлет тип 


// Убеждаемсл, что получили ссмлку на обБект-представителБ 
Console.WriteLine( 
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"Is proxy={0}"j RemotingServices . IsTnansparentPnoxy(mbrt) ); 

// Bce внглидит так, как будто mn внзмваем метод зкземплвра 
// MarshalByRefType, но на самом деле mn вћвнваем метод типа 
// представителд. Именно представители переносит поток в тот домен, 

// в котором находитсд обиект, и внзмвает метод длл реалиного обиекта 
mbrt . SomeMethod (); 

// Внгружаем новни домен 
AppDomain.Unload(ad2); 

// mbrt ссмлаетсл на правилннни обнект-представители; 

// обиект-представителн сснлаетсн на неправилинни домен 

try { 

// BbBbiBaeM метод, определеннни в типе представителн 
// Посколнку домен приложении неправилннми, подвллетсл исклтчение 
mbrt . SomeMethod( ); 

Console.WriteLine("Successful call."); 

} 

catch (AppDomainUnloadedException) { 

Console.WriteLine("Failed call."); 

} 

// ПРИМЕР 2. Доступ к обБектам другого домена 
// с продвижением по значенит 

Console.WriteLine("{0}Demo #2", Environment.NewLine) ; 

// Создаем новуи домен (с такими же параметрами затити 

// и конфигурированин, как в текушем) 

ad2 = AppDomain.CreateDomain("AD #2", null, null); 

// Загружаем нашу сборку в новми домен, конструируем обиект 
// и продвигаем его обратно в наш домен 

// (в деиствителнности mn получаем ссћшку на представители) 
mbrt = (MarshalByRefType) 

ad2.CreateInstanceAndUnwrap(exeAssembly, "MarshalByRefType"); 

// Метод возврашает КОПИК) возврашенного обБекта; 

// продвижение обиекта происходило по значенит, а не по ссћшке 
MarshalByValType mbvt = mbrt.MethodWithReturn(); 

// Убеждаемсд, что mn НЕ получили ссћшку на обиект-представителн 
Console.WriteLine( 

"Is proxy={0}", RemotingServices.IsTransparentProxy(mbvt)); 

// Кажетсн, что mn вшзБ 1 ваем метод зкземплнра MarshalByRefType, 

// и зто на самом деле так 

Console.WriteLine("Returned object created " + mbvt.ToStringO ); 

// Вђ 1 гружаем hobnh домен 
AppDomain.Unload(ad2); 

// mbrt ccbmaeTCR на деиствителнн^и обиект; 

продолжение & 
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// внгрузка домена не имеет никакого зффекта 
try { 

// BbBbiBaeM метод обвекта; исклк)чение не генерируетсл 
Console.WriteLine("Returned object created " + mbvt.ToString()); 
Console.WriteLine("Successful call."); 

} 

catch (AppDomainUnloadedException) { 

Console.WriteLine("Failed call."); 

} 

// ПРИМЕР 3. Доступ к обвектам другого домена 
// без исполвзованид механизма продвиженил 
Console.WriteLine("{0}Demo #3", Environment.NewLine); 

// Создаем новми домен (с такими же параметрами зашити 

// и конфигурированил, как в текушем) 

ad2 = AppDomain . CreateDomain("AD #2", null, null); 

// Загружаем нашу сборку в новши домен, конструируем обћект 
// и продвигаем его обратно в наш домен 

// (в деиствителвности mn получаем ссшлку на представителк.) 
mbrt = (MarshalByRefType) 

ad2.CreateInstanceAndUnwrap(exeAssembly, "MarshalByRefType"); 

// Метод возврашает обћект, продвижение которого невозможно 
// Генерируетсл исклкзчение 

NonMarshalableType nmt = mbrt.MethodArgAndReturn(callingDomainName); 

// До вмполненил зтого кода дело не доидет... 

} 

// Зкземпллрш допускашт продвижение по ссмлке через границш доменов 
public sealed class MarshalByRefType : MarshalByRefObject { 
public MarshalByRefType() { 

Console.WriteLine("{0} ctor running in {1}", 

this.GetType().ToString(), Thread.GetDomain().FriendlyName); 

} 

public void SomeMethod() { 

Console.WriteLine("Executing in " + Thread.GetDomain().FriendlyName); 

} 

public MarshalByValType MethodWithReturn() { 

Console.WriteLine("Executing in " + Thread.GetDomain().FriendlyName); 
MarshalByValType t = new MarshalByValType(); 
return t; 

} 

public NonMarshalableType MethodArgAndReturn(String callingDomainName) { 
// ПРИМЕЧАНИЕ : callingDomainName имеет атрибут [Serializable] 
Console.WriteLine("Calling from '{0}' to '{1}'.", 
callingDomainName, Thread.GetDomain().FriendlyName); 
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NonMarshalableType t = new NonMarshalableType(); 
return t; 

} 

} 

// Зкземплпрн допускатт продвижение по значенит через границн доменов 
[Serializable] 

public sealed class MarshalByValType : Object { 
private DateTime m_creationTime = DateTime.Now; 

// ПРИМЕЧАНИЕ : DateTime помечен атрибутом [Serializable] 

public MarshalByValType() { 

Console.WriteLine("{0} ctor running in {1}, Created on {2:D}", 
this .GetType(). ToStringO, 

Thread.GetDomain().FriendlyNamej 
m_creationTime); 

} 

public override String ToString() { 

return m_creationTime.ToLongDateString(); 

} 

} 

// Зкземпллрн не допускагат продвижение между доменами 
// [Serializable] 

public sealed class NonMarshalableType : Object { 
public NonMarshalableType() { 

Console.WriteLine("Executing in " + Thread.GetDomain().FriendlyName); 

} 

} 

Собрав и вмполнив зто приложение, мм получим следукицее: 

Default AppDomain's friendly name= Ch22-l-AppDomains.exe 
Main assembly=Ch22-l-AppDomains, Version=0.0.0.0, 

Culture=neutral, PublicKeyToken=null 

Demo #1 

MarshalByRefType ctor running in AD #2 

Type=MarshalByRefType 

Is proxy=True 

Executing in AD #2 

Failed call. 

Demo #2 

MarshalByRefType ctor running in AD #2 
Executing in AD #2 

MarshalByValType ctor running in AD #2, Created on Friday, August 07, 2009 
Is proxy=False 

Returned object created Friday, August 07, 2009 
Returned object created Friday, August 07, 2009 
Successful call. 

Demo #3 

MarshalByRefType ctor running in AD #2 

продолжение & 
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Calling fnom 'Ch22-l-AppDomains.exe' to 'AD #2'. 

Executing in AD #2 

Unhandled Exception: System.Runtime.Senialization.SenializationException: 

Туре 'NonManshalableType' in assembly 'Ch22-l-AppDomains, Vension=0.0.0.0, 

Cultune=neutnal, PublicKeyToken=null’ is not manked as senializable. 

at ManshalByRefType.MethodAngAndRetunn(Stning callingDomainName) 

at Pnognam.Manshalling() 

at Pnognam.Main() 

is not manked as senializable. 

at ManshalByRefType.MethodAngAndRetunn(Stning callingDomainName) 
at Pnognam.Manshalling() 
at Pnognam.Main() 

A тспс|) 1 . поговорим o том, что делает зтот код и как работает CLR. 

В методе Marshalling п первмм делом получаго ссмлку на обвект AppDomain, 
которми идентифицирует домен приложении, где в даннми момент вмполниетсн 
вмзмвагогции поток. В Windows поток всегда создаетсл в контексте одного про- 
цесса и проводит в нем всго свого жизнв. Однако между потоками и доменами при- 
ложении отсутствует однозначное соответствие. Доменм приложении относлтси 
к функционалвности CLR, Windows о них ничего не «знает». Так как в одном 
Windows-nponecce может сугцествоватБ несколБКО доменов приложении, поток 
может в разное времн вбшолннтб код разнкгх доменов. С точки зренгш CLR в каж- 
дбш момент времени поток ввшолннет код толбко в одном из доменов приложении. 
Поток может запроситв у CLR, код какого домен в нем ввшолннетсц в текугции 
момент, вБгзвав статическии метод GetDomain класса System . Threading . Thread или 
запросив статическое, предназначенное толбко длн чтенин своиство CurrentDomain 
класса System.AppDomain. 

Создаваемому домену можно присвоитв значимое имн — строку типа String, 
исполвзуемуго затем длч идентификации. Обкгчно зто оказБшаетсл полезнБш при 
отладке. Так как среда CLR создает основнои домен до ввшолненгш какого-либо 
кода, в качестве имени по умолчаниго беретсл имн исполннемого фаила. Moii метод 
Marshalling запрашивает имн основного домена через предназначенное толбко 
длнчтенгш своиство FriendlyName класса System.AppDomain. 

Далее, метод Marshalling запрашивает строгое ими сборки (загруженнои 
в ocHOBHori домен), которое определнет точку входа в метод Main, вБгзвшагогции 
Moii метод Marshalling. В зтои сборке определено несколкко типов: Program, 
MarshalByRefType, MarshalByValType и NonMarshalableType. Теперв рассмотрим 
три во многом сходнбгх друг с другом примера. 

Пример 1. Междоменное взаимодеиствие 
с продвижением по ссмлке 

В первом примере статическии метод CreateDomain типа System . AppDomain вбгзбг- 
ваетсн, чтобвг заставитв CLR создатБ новбш домен приложении в том же Windows- 
процессе. Тип AppDomain предоставлнет несколвко перегруженнБгх версии метода 
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CreateDomain; н рекомендуго вам изучитБ их и вмбратБ версиго, котораи болБше 
всего подоидет вам при написании кода созданин нового домена. Мои версгш зтого 
метода имеет три аргумента: 

□ Строка Stning содержит значимое имн дли нового домена. И передаго eii зна- 
чение "AD #2". 

□ Аргумент System . Secunity . Policy . Evidence содержит политику, которукз 
должна исполБЗОватБ среда CLR дли вБ1численгш набора разрешении дли до- 
мена. В зтом аргументе м передаго значение null, что 6 б 1 новбш домен прило- 
жении наследовал тот же набор разрешении, что и родителвскии. 06бшно длл 
созданин загцитнои грании,Б 1 вокруг кода домена приложении конструиругот 
обвект System . Secunity . PermissionSet, создагот в нем необходимвге обвектБ1 
разрешении (зкземплирБ1 типов, которвге реализугот интерфеис IPenmission), 
а затем передагот ссвшку на резулБтиругогции обвект PermissionSet перегру- 
женнои версии метода CreateDomain, принимагогцего PermissionSet. 

□ Аргумент System . AppDomainSetup задает параметрвг конфигурирации, которвге 
среда CLR должна применитБ к новому домену. И здесв н передаго значенгге null, 
что 6 бг иовбпг домен приложенгш наследовал конфигурациго родителвского. Что- 
6 бг домен получил особуго конфигурациго, надо создатк обвект AppDomainSetup, 
задатБ его своиства требуемвгм образом, а затем передатБ в метод CreateDomain 
ссвшку на резулБтиругогции обвект AppDomainSetup. 

Код метода CreateDomain создает иовбпг домен в процессе. Зтому домену при- 
сваиваетсл значимое имн, а также параметрвг загцитБг и конфигурацгш. У нового 
домена еств собственнан куча загрузчика, котораи пока пуста, потому что в него 
не загружено ни однои сборки. При создангш домена среда CLR не создает в нем 
никаких потоков; там не вБшолннетсн никакои код, пока вбг hbho не заставите поток 
ввгзватБ код домена приложении. 

ТеперБ, что 6 бг получитБ зкземплир обвекта в новом домене, надо сначала 
загрузитБ туда сборку, а затем создатк зкземшшр определенного в зтои сбор- 
ке типа. Именно зти операции и вБгполннет открбгтбги зкземпллрнБги метод 
CreateInstanceAndUnwrap класса AppDomain. Зтому методу передаготсн два аргумен- 
та: строка String, идентифициругогцаи сборку, которуго следует загрузитв в новбпг 
домен (на нее ссБшаетсл переменнан ad2), и строка String, содержагцаи ими типа, 
зкземплир которого надо создатБ. Метод CreateInstanceAndUnwrap заставллет 
ББгзБшагогции поток переити из текугцего домена в новбш. ТеперБ поток (которкги 
вБшолшгет вБгзов CreateInstanceAndUnwrap) загружает указаннуго сборку в новбш 
домен, а затем просматривает таблицу метаданнвгх с определенгшми типов сборки 
в поисках указанного типа (MarshalByRefType). Обнаружив нужнвш тип, поток 
вБгзБгвает конструктор MarshalByRefType безпараметровивозврагцаетслобратно 
в основнои домен, чтобвг метод CreateInstanceAndUnwrap мог вернутв ссбшку на 
новбги обвект MarshalByRefType. 
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ПРИМЕЧАНИЕ 

Сушествук)т перегруженнне версии CreatelnstanceAndllnwrap, которие позволлк)т 
Bbi3bieaTb конструктор типа с передачеи аргументов. 


Однако все не так радужно, как могло бн показатБСи. ВедБ CLR не позволиет 
переменнои (корннз), находнгцеисн в одном домене, ссћшатБСн на обвект из другого. 
Если 6 hi метод CreateInstanceAndUnwrap просто вернул ссвшку на обвект, зто на- 
рушило 6 ki изо.тацик), а ведБ именно ради нее создавалисБ домс1Њ|! Позтому непо- 
средственно перед возврагцением ссбшки на обвект метод CreateInstanceAndUnwrap 
вБшолннет некоторБШ дополнителБНБге операции. 

Обратите внимание, что тип MarshalByRefType наследует от специалвного 
базового класса System.MarshalByRefObject. Обнаружив, что метод Create- 
InstanceAndUnwrap ввшолниет продвижение обвекта типа, производного от 
MarshalByRefObject, CLR ввшолниет продвижение обвекта по ссБ 1 лке в дру- 
roii домен. Поиснго, что означает продвижение обвекта по ссБ 1 лке из одного 
домена (в котором обвект 6 бш создан) в другои (в котором вБгзвшаетси метод 
CreateInstanceAndUnwrap). 

Когда домену-источнику нужно передатн ссбшку на обвект в целевои домен 
приложении или вернутв ее обратно, CLR определиет в куче загрузчика зтого 
домена тип представителм (ргоху). Зтот тип определиетси посредством метадан- 
нб 1 х исходного типа, представителем которого он нвлиетсл, позтому вбнлидит он 
в точности как исходнбш тип — у него совпадагот все зкземплнрнвге членвг (ciioii- 
ства, собвтш и методБ 1 ). ЗкземплирнБге поли к типу не относлтси, но об зтом mhi 
поговорим чутв позже. В новом типе деиствителвно определиготсн некоторБШ 
зкземплнрнБге по./ш, но они не идентичнБ1 полнм исходного типа данннгх. Вместо 
зтого зти полн указБшагот, которпш из доменов «владеет» реалвнБш обвектом и как 
наити зтот oo'beici' в домене-владелвце. (Внутренне обБект-представителБ исполб- 
зует зкземплнр GCHandle, которнш ссБшаетси на реалБНБпг обвект. Тип GCHandle 
обсуждаетсл в главе 21 ). 

После определенин зтого типа в целевом домене метод CreateInstanceAndUnwrap 
создает зкземплир типа представителн, инициализирует его полн таким обра- 
зом, чтобвг они указБшали на домен-источник и реалБНБш обвект, и возврагцает 
в целевои домен ссвшку на обБект-представителБ. В моем варианте кода на зтот 
представителв ссБ1лаетсн переменнаи mbrt. При зтом возврагценнБ1и методом 
CreateInstanceAndUnwrap обвект не ивлнетсл зкземплнром типа MarshalByRefType. 
Обвгчно CLR не разрешает приведение к несовместимвш типам, однако в зтои си- 
туации преобразование ввшолниетси, потому что членБг зкземплнров нового и ис- 
ходного типов совпадагот. В сугцности, если bbi исполвзуете обБект-представителБ 
длн вБИОва метода GetType, представителв вводит вас в заблуждение, представлннсБ 
обвектом MarshalByRefType. 

Впрочем, при желании можно узнатн, что обвект, возврагценнБ1и методом 
CreateInstanceAndUnwrap, в реалвности ивлнетси ссбшкои на обБект-представителБ. 
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Длн зтого мм исполћзуем открБПБш статическии метод IsTransparentProxy типа 
System . Runtime . Remoting . RemotingService, которому в качестве параметра 
передаетсл ссБшка, возврагценнап методом CreateInstanceAndUnwrap. Если метод 
IsTransparentProxy возврагцает значение true, значит, обвект нвлнетсл предста- 
вителем. 

Итак, мое приложение исполБзует представителн длн вБ130ва метода SomeMethod. 
Так как переменнан mbrt ссБшаетсн на обБект-представителБ, вБтзБшаетсн реализацил 
зтого метода в представителе. В неи информацгш из полеи обБекта-представителн 
исполБзуетсл длл направленгш вБ13Бшагогцего потока из основного домена при- 
ложенгш в новбпг. ТеперБ . iioop.ic деиствгш зтого потока вбшолннготсл в контексте 
безопасности и конфигурации нового домена. Далее поток исполБзует поле GCHandle 
обп>екта- 11 рсдста is ител з длн поиска в новом домене реалБного обвекта, после чего 
вБ13Бшает длн него метод SomeMethod. 

Естб два способа узнатБ, что запрашивагогции поток перешел от основного к ново- 
му домену. Во-первБ 1 х, в методе SomeMethod н вБШБшаго метод Thread .GetDomain() . 
FriendlyName. В резулБтате возврагцаетсн AD #2 (что подтверждаетсл вбгходнбши 
даннБши), так как поток теперБ вБшолннетсл в новом домене, созданном методом 
AppDomain . CreateDomain с параметром AD #2 в качестве значимого имени. Во- 
вторБгх, при пошаговом вБшолненгш кода в отладчике с открБ1ТБш окном Call Stack 
строка [AppDomain Transition] отмечает переход потока через границу между 
доменами (рис. 22.2). 
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Рис. 22.2. Переход между доменами в окне отладчика Call Stack 


Когда реалБНБш метод SomeMethod возврагцает управление методу SomeMethod 
представителн, тот переправлнет поток обратно в основнои домен, в котором и про- 
должаетсл вБшолнение кода. 
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ПРИМЕЧАНИЕ 

Когда поток в одном домене Bbi3bieaeT метод другого домена приложении, поток 
переходитотдомена кдомену. Зто означает, что вмзови методачерез границу между 
доменами приложенил внтолнч 1 отсл синхронно. Однако считаетсл, что в каждни 
момент времени поток находитсл толико в одном домене. Длл внполненил кода в не- 
сколикихдоменах приложении одновременно придетсл создавати дополнителвнв 1 е 
потоки и заставлчти их внполнптв нужнни код в нужннх доменах. 

Далее мое приложение вмзмвает открмтми статическии метод Unload типа 
AppDomain, чтобм заставитБ CLR вБ 1 грузитБ указаннБпг домен вместе со всеми 
загруженнвши в него сборками. Одновременно инициируетсл уборка мусора длн 
освобожденин всех обЂектов ввггружаемого домена. На зтом зтапе переменнан mbnt 
основного домена все егце ссБшаетсл на нужннш обЂект-представителБ; однако 
сам обЂект-представителБ болБше не ссБ1лаетси на нужнБш домен приложении 
(посколБку тот уже вБ1гружен). Когда основнои домен пБггаетси исполБЗОватБ 
обБект-представителБ длн вБгзова метода SomeMethod, вБгзвшаетсн реализацин зтого 
метода, определеннан в представителе. Реализацин представители ввшсниет, что 
домен приложении, в котором находилси реалБНБП! обвект, уже вБггружен, и метод 
SomeMethod генерирует исклкзчение AppDomainUnloadedException, информируи 
вБ13Б1вак)гции код о невозможности ввшолненгш операцгш. 

Как видите, команда разработчиков CLR в Microsoft проделала огромнуго работу, 
чтобвг обеспечитБ изолнцшо доменов приложенгш. И зто дело исклгочителвнои важ- 
ности, так как даннаи функционалвностБ все активнее исполБзуетсн при решенгш 
повседневнБгх задач. ilcno, что доступ к обвектам через границБг доменов посред- 
ством продвиженгш по ссвшке свизан с некоторои потереи производителвности, 
позтому исполБЗОвание таких операцгш надо сводитб к минимуму. 

Л обегцал подробнее рассказатБ об зкземплирнБгх полих. Они определлготсн 
в типе, производном от ManshalByRefObject, однако не нвлнготси частвго представи- 
телн и отсутствугот в обБекте-представителе. Когда вбг пишете код, читагогции и из- 
менлгогции значенгш полеи зкземплнров типа, производного от ManshalByRefOb ject, 
JIT -комшиштор генерирует код, исполБзугогцгш обЂект-представителБ (что6бг 
наити реалБНБге домен и обвект), вБИБшаи соответственно метод FieldGetten или 
FieldSetten класса System .Ob ject. Зто закрвгтБге и недокументированнБге методБг; 
в сугцности, длн считвшангш и записи значенгш в поле в них исполБзуетсн отражение. 
Так что хотн вбг и имеете доступ к поллм типа, производного от ManshalByRefObject, 
производителБностБ от зтого страдает особенно силбно, потому что дли такого до- 
ступа среде CLR приходитси вБгзБшатБ методБг. ПроизводителБностБ значителБно 
снижаетсн, даже если обвект, к которому происходит обрагцение, находитси в ло- 
калвном домене приложенгш 1 . 


1 Если бн среда CLR требовала закрвгтости всех полеи (что рекомендуетсл длл хорошеи 
инкапсуллции), методм FieldGetter и FieldSetter не должнм бмли бм сушествоватм В итоге 
к поллм осталсл бн толвко непосредственнни доступ из методов, что избавило бм нас от 
потерБ производителБности. 
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ПРИМЕЧАНИЕ 

Чтобм продемонстрировати, сколвзначителвнои может 6biTb потерл производителе- 
ности, л написал следукхции код: 

private sealed class NonMBRO : Object { public Int32 х; } 

private sealed class MBRO : MarshalByRefObject { public Int32 х; } 

private static void FieldAccessTiming(){ 
const Int32 count = 100000000; 

NonMBRO nonMbro = new NonMBRO(); 

MBRO mbro = new MBRO(); 

Stopwatch sw = Stopwatch.StartNew(); 

for (Int32 c = 0; c < count; c++) nonMbro.x++; 

Console.WriteLine("{0}", sw.Elapsed); // 00:00:00.4073560 

sw = Stopwatch.StartNew(); 

for (Int32 c = 0; c < count; c++) mbro.x++; 

Console.WriteLine("{0}", sw.Elapsed); // 00:00:02.5388665 


Доступ к екземплпрному полкз класса NonMBRO, производного от класса Object, 
занлл около 0,4 секундм, в то времв как длп доступа к классу MBRO, производному 
от MarshalByRefObject, потребовалосв 2,54 секундм. Как видите, во втором случае 
процесс занчл в 6 раз болвше времени! 


Наконец, с точки зрешш удобства исполБЗОванин в производном от 
MarshalByRefObject типе не следует определлтБ какие-либо статические членм. 
Дело в том, что к статическим членам всегда обратцаготсн в контексте вмзмваготцего 
домена приложении. Никакои передачи между доменами 6 мтб не может, посколћку 
информацин о целевом домене содержитсн в обЂекте-представителе, но такои обвект 
при вмзове статического члена попросту отсутствует. МоделЂ программировании, 
предусматривагогцан вмполнение статических членов типа в одном домене, в то вре- 
мн как зкземплнрнме членм вмполннготси в другом, бмла бм оченЂ неудачнои. 

Так как во втором домене отсутствугот корни, исходнми обвект, на которми 
ссмлалсн представителЂ, может 6 мтђ отправлен в мусор. Разумеетсн, зто — не 
идеалЂнми подход. Однако если бесконечно хранитБ исходнми обвект в памити, 
он останетси там даже после удаленин представителл, что тоже не оченЂ хорошо. 
В CLR зта проблема решаетсл при помоши диспетчера аренди (lease manager). 
Создав дли обвекта представителБ, CLR сохраниет обЂект в течение 5 минут. Если 
за зто времн через представителв не последовало ни одного ввгоова, обвект деакти- 
вируетсл (deactivated) и освобождает памнтв при следуговдеи уборке мусора. После 
каждого вБ130ва обвекта диспетчер обновлиет его срок арендБц в резулвтате обЂект 
гарантированно остаетси в памнти евде 2 минутБ1 и толбко потом деактивируетсл. 
При попБ 1 тке вБ13ватБ через представителБ обБект с истекшим сроком арендБ 1 CLR 
генерирует исклгочение System . Runtime . Remoting . RemotingException. 
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Дли переопределенин заданного по умолчашпо времени в 5 и 2 минутм исполБзуи- 
те виртуалБНБш метод InitializeLifetimeServices типа MarshalByRefObject. До- 
полнителБнук) информациго по даннои теме вбг можете наити в SDK -документации 
на .NET Framework. 

Пример 2. Междоменное взаимодеиствие 
с продвижением по значеникз 

Зтот пример похож на предБвдугции. В нем точно так же создаетси второи домен 
приложении. ЗатемвввдБшаетсн метод CreateInstanceAndUnwrap длн загрузки Toii 
же сборки в новБпг домен и созданин в нем зкземплнра обвекта MarshalByRef Туре. 
Далее CLR создает длн обвекта представителв, и переменнои mbrt (в основном до- 
мене) присваиваетсн ссвшка на него. Теперв при помогци созданного представителн 
и вБгзБшаго метод MethodWithReturn. Зтот метод без параметров будет ввшолнен 
в новом домене, а перед тем как вернутв ссбшку на обвект основному домену, он 
создаст зкземплнр типа MarshalByValType. 

Тип MarshalByValType ненвлнетси производнвш от System.MarshalByRefObject, 
а значит, CLR не может определитБ тип представителн длн созданин его зкземплнра; 
то еств обвект нелБЗи продвинутБ по ссншке через границу домена. 

Однако благодарн наличик) у типа Ма r shalByValType настраиваемого атрибута 
[Serializable] метод MethodWithReturn может вбшолнитб продвижениеобвекта 
по значеншо. Сеичас mbi поговорим о том, что происходит при продвижении обв- 
екта по значеншо из одного домена (исходного) в другои (целевои). А дополни- 
телвнук) информацшо о механизмах сериализации и десериализации bhi наидете 
в главе 24. 

Когда исходному домену нужно передатв ссбшку на обвект в целевои домен 
(или возвратитв ссбшку из целевого домена), CLR сериализует зкземшшршле 
полн обвекта в баитошли массив, которвш затем копируетси. После зтого CLR 
десериализует баитоввш массив в целевом домене. Зто ввшуждает CLR загрузитБ 
в целевои массив сборку (если она егце не загружена), в которои определен десе- 
риализованнвш тип. Далее CLR создает зкземшшр типа и исполБзует значении из 
баитового массива дли инициализации полеи обвекта так, чтобвг они полностбго 
совпадали со зиаченилми исходного обвекта. Иначе говорн, CLR делает точнуго 
копиго исходного обвекта в целевом домеие. Затем метод MethodWithReturn воз- 
врагцает ссвшку на зту копиго; в резулвтате наш обвект оказБгваетси продвинутБгм 
по значеншо через границу домена. 

ВНИМАНИЕ 

При загрузке сборки CLR исполБзует политики и конфигурацикз целевого домена 
(в частности, удомена приложении можетбБ 1 ТБ другои каталогАррВазе или инфор- 
мацил о перенаправлении версии). Зти различил в политиках могут помешатБ CLR 
в поиске сборки. Если сборку загрузитБ не удаетсл, возникает исклкзчение, а целевои 
домен приложении не получает ссмлку на обЂект. 
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На зтом зтапе обЂектм в исходном и целевом доменах сушествугот независимо 
друг от друга, позтому их состоннгш также могут меннтБСн независимо. Если в ис- 
ходном домене нет корнеи, предохраннгогцих исходнми обвект от уничтоженгш 
уборгциком мусора (как в созданном много приложении), его памитБ будет осво- 
бождена при следугогцеи уборке. 

Чтобвг убедитБСл, что обЂект, возврагценнБш методом MethodWithReturn, не 
нвлиетсл ССБ1ЛКОИ на обЂект-представителБ, мое приложение вБгзБгвает открвг- 
тбги статическии метод IsTrasparentProxy тггпа System . Runtime . Remoting . 
RemotingService, передавал ему в качестве параметра ссвглку, возврагценнуго 
методом MethodWithReturn. Как видно из резулвтатов работвг программБг, метод 
IsTrasparentProxy возврагцает значение f alse, означагогцее, что обвект нвлнетси 
реалвнБгм обЂектом, не представителем. 

Итак, мон программа исполвзует реалБНБги обЂект длн вБгзова метода Т oString. 
Так как переменнан mbvt ссвглаетсл на реалБНБш обЂект, вБгзБгваетсл реалвнал 
реализацгш зтого метода и никаких переходов между доменами приложенгш не 
происходит. Зто легко проверитБ, проанализировав информациго в окне Call Stack 
отладчика: строка [AppDomain Transition] там не понвитсл. 

Чтобвг более убедителвно доказатБ, что зто не представителБ, мое приложение 
вБггружает новбги домен, после чего пБгтаетсл снова ввгзватБ метод ToString. В от- 
личие от примера 1 на сеи раз запрос успешно вБгполннетсл, потому что внггрузка 
нового домена нггкак не влилет на обвектБг, расположеннБге в основном домене, 
в том числе на обвект, продвинутБш по значениго. 

Пример 3. Междоменное взаимодеиствие без продвиженив 

Зтот пример оченв похож на описаннБге ранее примерпг 1 и 2. Точно так же соз- 
даетсл новбги домен, после чего вБгзБгваетсч метод CreateInstanceAndUnwrap дли 
загрузки тои же сборкгг в новбги домен приложенгш и созданил в нем обвекта 
MarshalByValType. Переменнан mbrt ссвглаетсл на представителБ зтого обЂекта. 

Затем через зтого представителл н вБгзвгваго метод MethodArgAndReturn, при- 
нимагогции один аргумент. Так как среда CLR должна контролироватв изолициго 
домена, она не может просто передатБ ссбглку на аргумент в новбги домен приложе- 
нии. Дли обнекта, принадлежагцего к типу, производному от MarshalByRefObject, 
CLR создает представителв и вБгполниет продвижение обвекта по ссвглке. Если 
тип обвекта помечен атрибутом [Serializable], CLR сериализует обвект (и его 
потомков) в баитовБш массив, пакует зтот массггв в новбги домен и десериализует 
его в граф обвекта, передав коренв графа методу MethodArgAndReturn. 

В зтом примере н передаго обвект System.String через границвг домена. Тггп 
System . String не нвлнетсл производнвгм от класса MarshalByRefOb ject, а значит, 
CLR не может создатБ представителн. К счаствго, обЂект System.String помечен 
атрибутом [Serializable] , позтому CLR в состоннгшпродвинутвего по значениго, 
и код будет работатБ. Обратите внимание, что длл типа String CLR вБгполшгет 
специалБнуго оптимизациго. Продвигаи обвект String через границу домена, CLR 
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просто передает ссмлку на него; копиго обкекта она не делает. Подобнал оптимизацил 
оказмваетсн возможнои благодарн неизменности обвектов типа Stning, что не дает 
коду из одного домена повредитБ символм обвекта Stning из другого. ДополнителБ- 
нуго информациго о неизменности обЂектов данного типа вбг наидете в главе 14 1 . 

Внутри метода MethodAngAndRetunn и ввшожу передаваемуго в него строку, 
что 6 б 1 показатБ ее переход через границу домена. Затем и создаго зкземплнр типа 
NonManshalableType и возврагцаго ссвшку на зтот обвект в основнои домен. Так как 
тип NonManshalableType не нвлнетсл производнвш от System.ManshalByRefObject 
инепомеченатрибутом [Senializable] , метод MethodAngAndRetunn неможетпро- 
двинутБ обвект по сскшке или по значениго. То естБ у нас нет способа передатБ о6ђ- 
ект через границБг домена. Что 6 б 1 указатБ на зтот факт, метод MethodAngAndRetunn 
генерирует в основном домене исклгочение SenializationException. Так как мон 
программа не умеет его перехватвшатБ, она просто прекрагцает свого работу. 


Вмгрузка доменов 

Одна из замечателБНБгх особенностеи CLR — возможностб вБггрузки доменов 
приложении. При зтом ввшружаготсл и все загруженнБге в них сборки, а также 
освобождаетсл куча загрузчика доменов. Провести зту процедуру легко: доста- 
точно ББгзватБ статическии метод Unload класса AppDomain (как показано в моем 
приложении в начале r. iai:i,i). Зто заставлнет CLR вбшолнитб набор операции по 
корректнои вБггрузке указанного домена. 

1. CLR приостанавливает все потоки в процессе, которвге когда-либо вбшолннли 
управлиемБш код. 

2. CLR проверлет все стеки на наличие потоков, которвге в текугции момент bbi- 
полннгот код вБшружаемого домена или могут рано или поздно вернутБСл к вбг- 
полнениго такого кода. CLR вкшуждает все потоки, в стеке которшх находитси 
ББшружаемБп! домен, сгенерироватБ исклгочение ThneadAbontException (при 
зтом вБшолнение потока возобновлиетсн). В резулвтате потоки переходнт 
к вБшолнениго блоков f inally, то еств корректно завершагот свого работу. При 
отсутствии кода, перехватвшагогцего исклгочение ThneadAbontException, оно 
переходит в разрлд необработаннвш и <<проглатБ 1 ваетсл» CLR; поток заверша- 
етсл, но процессу разрешаетсл продолжитв работу. Такое поведение отличаетси 
от стандартного, потому что в лго6б1Х других ситуацинх при возникновении 
необработанного исклгоченгш CLR уничтожает процесс. 


1 Кстати, именно позтому класс System.String лвллетсл запечатаннБш. Если 6бг зто 6бшо не 
так, вб 1 могли 6 б 1 определлтБ собственнБге классБг, производнБге от String, и добавллтБ к ним 
собственнБге полл. В резулнтате среда CLR не смогла 6бг гарантироватБ неизменностБ строк. 
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ВНИМАНИЕ 

CLR неуничтожит немедленно поток, которми вмполнлет код блокаАпаПу или catch, 
конструктора класса, критическои области или неуправллемв 1 и код. Уничтожение 
таких потоков сделало 6bi невозможнмм вмполнение кода очистки, восстановленил 
после ошибок, инициализации типа, критического кода или лкзбого кода, которми 
CLR не знает как обраба™ватш Зто стало бм причинои непредсказуемого поведенил 
приложении и полвленикз дмр в системе безопасности. Уничтожаемому потоку раз- 
решаетсл закончитБ ввшолнение таких блоков, и толвко после зтого CLR вв 1 нуждает 
его сгенерироватв исклгачение ThreadAbortException. 


3. После вмгрузки из домена всех потоков, обнаруженнмх на втором шаге, CLR 
проходит по куче и устанавливает флаг длл каждого обЂекта-представителл, 
которми ссмлаетсн на обвект, созданнми в вмгружаемом домене. Так обЂектм- 
представители «узнагот», что реалвнми обЂект, на которми они ссмлаготсн, 
уничтожен. В резулнтате при попмтке вмзватЂ метод «неправилЂного» обнекта- 
представители понвлиетсл исклгочение AppDomainUnloadedException. 

4. CLR инициирует принудителвнуго уборку мусора, чтобм освободитн памитЂ, 
занитуго обЂектами вмгружаемого домена. Вмзмваготси методм финализации 
дли зтих обвектов, даван им шанс вмполнитђ нужнуго очистку. 

5. CLR возобновлиет работу всех оставшихси потоков. Поток, вмзвавшии метод 
AppDomain . Unload, продолжает работу; вмзовм AppDomain . Unload вмполннготсн 
синхронно. 

В моем приложении всго работу вмполннет один поток. Всикии раз, когда 
код приложенин вмзмвает метод AppDomain .Unload, в вмгружаемом домене не 
оказмваетсн потоков, позтому CLR не приходитсн генерироватв исклгочение 
ThreadAbortException (о нем мм поговорим чутв позже). 

Кстати, при вмзове потоком метода AppDomain .Unload CLR ждет 10 секунд, 
чтобм потоки вмгружаемого домена могли его покинутв. Если после зтого поток, 
вмзвавшии метод AppDomain.Unload, не возврагцает управление, он генерирует 
исклгочение CannotUnloadAppDomainException, и домен может бмтв (а может и не 
6 мтђ) вмгруженнмм в будугцем. 

ПРИМЕЧАНИЕ 

Если поток, Bbi3BaBLUHM AppDomain.Unload, находитсч в вв 1 гружаемом домене, CLR 
создает другои поток, которми пи1таетсч вмгрузитв домен. riepBbin поток принуди- 
TenbHO генерирует исклкзчение ThreadAbortException и вмполнчет раскрутку — поиск 
и очистку всех операции, начатмх ниже по стеку вмзовов. HoBbin поток дожидаетсн 
вмгрузки домена, а затем завершаетса. В случае сбоч внгрузки новми поток попро- 
бует обработа™ искшочение CannotUnloadAppDomainException, но так как нет кода, 
вмполнчемого зтим новмм потоком, перехватити зто исклкзчение нелвзл. 
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Мониторинг доменов 

Хост-приложение умеет отслеживатБ потреблиемћге доменом pecypcni. НекоторБге 
хостб1 на основе зтои информации принудителвно внггружагот домен, если вдруг 
потребление им па.мити или ресурсов процессора вбгходит за разумнБге с точки 
зренил хоста пределБк Мониторинг позволлет также сравнитв потребление ресур- 
сов различнвши алгоритмами и сделатБ вБгбор. Но так как зта операцин влгшет на 
производителБностБ, она инициируетсл вручнуго путем присвоенгш статическому 
своиству MonitoringEnabled класса AppDomain значенгш true. При зтом вклгочаетсн 
мониторинг всех доменов. Вбгклгочитб его уже пе.њзи; попБгтка присвоитБ своиству 
MonitoringEnabled значение false приведет к исклгочениго ArgumentException. 

При вклгоченном мониторинге код может исполБЗОватв четБгре предназначеннБгх 
толбко длн чтенгш своиства класса AppDomain: 

□ MonitoringSurvivedProcessMemorySize. Зто статическое своиство типа Int64 
возврагцает число баитов, исполвзуемБгх в даннвги момент всеми доменами под 
управлением текугцего зкземплира CLR. Значение верно с момента последнеи 
уборкгг мусора. 

□ MonitoringTotalAllocatedMemorySize. Зто своиство зкземплира типа Int64 
возврагцает количество баитов, ввгделеннБгх определеннБгм доменом. Значение 
верно с момента последнеи уборки мусора. 

□ MonitoringSurvivedMemorySize. Зто своиство зкземплнра типа Int64 возврагца- 
ет количество баитов, которвге в настонгцее времн исполБзуготсн определеннБгм 
доменом. Значение верно с момента последнеи уборкгг мусора. 

□ MonitoringTotalProcessorTime. Зто своиство зкземплира типа TimeSpan воз- 
врагцает процессорное времи, исполвзованное определеннвгм доменом. 

Следугогции класс демонстрирует, как при помогци трех из зтих своиств узнатв 
об изменении состоннгш домена за некии промежуток времени: 

private sealed class AppDomainMonitorDelta : IDisposable { 
private AppDomain m_appDomain; 
private TimeSpan m_thisADCpu; 
private Int64 m_thisADMemoryInUse; 
private Int64 m_thisADMemoryAllocated; 

static AppDomainMonitorDelta() { 

// Проверлем, что вклнгчен режим мониторинга домена 
AppDomain.MonitoringlsEnabled = true; 

} 

public AppDomainMonitorDelta(AppDomain ad) { 
m_appDomain = ad ?? AppDomain.CurrentDomain; 
m_thisADCpu = m_appDomain.MonitoringTotalProcessorTime; 
m_thisADMemoryInUse = m_appDomain.MonitoringSurvivedMemorySize; 
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m_thisADMemoryAllocated = 

m_appDomain.MonitoringTotalAllocatedMemorySize; 

} 

public void Dispose() { 

GC.Collect(); 

Console.WriteLine("FriendlyName={0}j CPU={l}ms" л 
m_appDomain.FriendlyName л 
(m_appDomain.MonitoringTotalProcessorTime - 
m_thisADCpu).TotalMilliseconds); 

Console.WriteLine( 

" Allocated {0:N0} bytes of which {1:N0} survived GCs"j 
m_appDomain.MonitoringTotalAllocatedMemorySize - 
m_thisADMemoryAllocated, 

m_appDomain.MonitoringSurvivedMemorySize - m_thisADMemoryInUse); 

} 


A зто — пример примененин класса AppDomainMonitorDelta: 

private static void AppDomainResourceMonitoringO { 
using (new AppDomainMonitorDelta(null)) { 

// Вмделение около 10 миллионов баитов, 

// KOTopbie переживут сборку мусора 
var list = new List<Object>( ) j 

for (Int32 х = 0; х < 1000; x++) list.Add(new Byte[10000]); 

// Вмделение около 20 миллионов баитовЈ 
// KOTopbie HE переживут уборку мусора 

for (Int32 х = 0; х < 2000; х++) new Byte[10000].GetType(); 

// Прокрутка процессора около 5 секунд 
Int64 stop = Environment.TickCount + 5000; 
while (Environment.TickCount < stop) ; 

} 


При вмполнении зтого кода вмводитсн следугогции резулћтат: 

FriendlyName=03-Ch22-l-AppDomains,exej CPU=5031 . 25ms 
Allocated 30,159,496 bytes of which 10,085,080 survived GCs 


Уведомление o первом управллемом 
исклкзчении домена 

С каждмм доменом свизан набор методов обратного вмзова, активизиругогцихсн, 
когда CLR начинает искатБ внутри домена блоки catch. Зти методм могут вмпол- 
ннтб записи в журнал, кроме того, хост в состолнии исполБЗОватБ отот механизм 
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дд л отслеживанин сгенерированнмх внутри домена исклгочении. Обратнме вмзовм 
не могут обработатБ исклгочение или <<поглотитб» его; они просто получагот уве- 
домление. Длн регистрации такого метода обратного вћгзова достаточно добавитБ 
делегат к зкземплнру со6бтгил FinstChanceException класса AppDomain. 

Среда CLR в данном случае работает так: при первом понвлении исклгоченин 
она задеиствует лгобои из методов обратного ввгзова FirstChanceException, зареги- 
стрированнБги в домене, ставшем источником исклгоченин. Затем CLR игцет в стеке 
зтого домена блоки catch. Если какои-то из зтих блоков обрабатвшает исклгочение, 
вБшолнение программБг возврагцаетсн в обвганБш режим. Если же такои блок отсут- 
ствует, CLR идет наверх стека вБгзвшагогцего домена и снова генерирует то же самое 
исклгочение (после его сериализации и десериализации). Однако зто исклгочение 
начинает восприниматБСн, как новое, и CLR задеиствует методвг обратного вБгзова 
FirstChanceException, зарегистрированшче на даннвш момент в текугцем домене. 
Процесс продолжаетсл, пока не будет достигнут верх стека потока. Если в резулвтате 
исклгочение так и не удастсл обработатв, CLR завершает процесс. 


Исполвзование хостами 
доменов приложении 

И уже рассказБгвал о хостах: как они загружагот CLR, как хост может заставитв 
CLR создатБ или вБггрузитБ домен приложении. Теперн, что6бг перевести разговор 
в более конкретное русло, mbi рассмотрим несколвко о6бшнб1х сценариев, касаго- 
гцихси хостинга и доменов приложении. В частности, и расскажу, как paam.ie типб1 
приложении вбшолннгот хостинг CLR и управлнгот доменами приложении. 

Исполнлемме приложенин 

КонсолБНБ 1 е приложенгш, приложение NT Service, приложенгш Windows Forms 
и приложенгш Windows Presentation Foundation (WPF) нвлнготси саморазмегцат- 
гцимисл (self-hosted) и снабженм управлнемвши ЕХЕ-фаилами. Е1нициализировав 
процесс при помогци такого фаила, Windows загружает оболочку совместимости, 
которал исследует информациго в заголовке CLR, содержагцугоси в сборке при- 
ложенгш (ЕХЕ-фаиле). Зта информацгш указвшает версиго CLR, котораи исполб- 
зоваласБ при сборке и тестировангш приложенгш. Именно с ее помогцбго оболочка 
совместимости определлет, какуго версиго CLR следует загрузитв в процесс. Загрузив 
и инициализировав среду, оболочка совместимости снова исследует заголовок ее 
сборки, что6б1 определитБ, какои метод лвлнетсл точкои входа приложенгш (Main). 
CLR вБИБшает зтот метод, и приложение начинает работу. 

В процессе работнг код обрагцаетсл к другим типам. При сскшке на тип, содер- 
жагцеисн в другои сборке, CLR находит зту сборку и загружает ее в тот же домен. 
Туда же загружаготсл и все прочие сборки, на которвге имеготсл ссбглки. После 
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возврашешш управлении методом Main Windows-npon,ecc завершает cboio работу 
(ликвидирун основнои и все прочие доменм). 


ПРИМЕЧАНИЕ 

Кстати, длл завершенил Windows-npou,ecca со всеми его доменами можно восполвзо- 
ватвсл статическим методом Exit класса System.Environment. Зто caMbiti корректнми 
способ завершенил процесса, таккакданни 1 и методсначала вмзв 1 ваетметодм фина- 
лизации всех обвектов в управллемои куче, а затем освобождает все неуправллемме 
СОМ-обвектм в CLR. После зтого Bbi3biBaeTcn Win32-^yHKpnn ExitProcess. 


Приложение может заставитБ CLR создатБ дополнителБнме доменм в адресном 
пространстве процесса. Собственно, именно зто и происходит в моем приложении, 
код которого представлен в начале зтои главм. 


ПолнофункционалБнме интернет-приложенил Silverlight 

Версгш CLR дли разработаннои в Microsoft динамическои технологии Silverlight 
отличаетси от версии обмчнои платформм .NET Framework дли настолБнмх ком- 
пБготеров. После установки средм Silverlight перемегцение на саит, которми исполб- 
зует зту среду, заставлиет Silverlight CLR (CoreClr.dll) загрузитБ браузер (причем 
зто может 6мтб вовсе не Internet Explorer — вм можете вообгце не исполБЗОватБ 
Windows). Каждћги злемент управленин Silverlight на странице работает в собствен- 
ном домене. Когда полБЗОвателБ закрБшает вкладку или переходит на другои саит, 
то доменвг всех неисполвзуемБгх злементов управленин Silverlight ввггружаготси. 
Код Silverlight в домене запускаетсн в песочнице (sandbox) с ограниченнои зашитои 
и не может причинитв какого-либо вреда полвзователго или машине. 


Microsoft ASP.NET и веб-службн XML 

ASP.NET — зто библиотека ISAPI (реализованнаи в фаиле ASPNet_ISAPI.dll). При 
первом запросе клиентом URL -адреса, обрабатвшаемого зтои библиотекои, ASP. 
NET загружает CLR. Когда клиент обрагцаетсн с запросом к веб-приложениго, 
ASP.NET определиет, 6бши ли уже такие запросБг Если даннБш запрос ивлиетси 
перввш, CLR получает команду создатк длн данного веб-приложенин новбпг домен 
(каждое приложение идентифицируетсн собственнБгм виртуалБНБш корневБш 
каталогом). Далее ASP.NET заставлнет CLR загрузитв в новбш домен сборку, 
предоставлигогцуго нужнвш тип, в новбш домен приложении, создает зкземплнр 
зтого типа и начинает вБ13БшатБ его методБ1 дли исполнешш запроса клиента. 
При наличии ссбглок на другие типбг CLR загружает в домен веб-приложении 
дополнителБНБШ сборки. 

При поступлении запроса к уже работагогцему веб-приложениго ASP.NET вместо 
нового домена создает новбш зкземплнр типа веб-приложенин в сугцествугогцем 
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и начинает вмзмватБ его методБг. При отом вБ13Б1ваемБ1е методБг оказБшаготсл уже 
преобразованнБши JIT -компиллтором в машиннвш код, позтому следугогцие кли- 
ентские запросБг обрабатБшаготсл намного брострсс. 

Если клиент обрагцаетсл с запросом к другому веб-приложениго, ASP.NET за- 
ставлиет CLR создатв повбри домен. 06 бино он создаетсл в том же рабочем про- 
цессе, в котором работагот другие доменвг приложении. Зто значит, что в одном 
Windows-npouecce может работатв несколвко веб-приложении, что поввгшает 
производителБностБ системБг В зтом случае сборки длл раз. m>i х веб-приложении 
загружаготсн в собственнвпт домен каждого из них — зто необходимо длн изолнции 
кода и обвектов веб-приложенгш от других веб-приложении. 

ЗамечателБнаи особенностн ASP.NET — возможностб изменнтБ код веб-саита 
без остановки веб-сервера. Когда фаил на жестком диске саита мениетси, ASP.NET 
обнаруживает зто, ввггружает домен, содержагции старуго версиго (после заверше- 
нгш текугцего запроса), а затем создает новбш домен, загружан в него новвге версии 
фаилов. При зтом ASP.NET исполБзует особуго функциго доменов, назвшаемуго 
теневим копированием (shadow copying). 

Microsoft SQL Server 

Microsoft SQL Server относитсл к неуправлиемБш приложенгшм, так как болншаи 
частБ кода SQL-cepBepa написана на неуправлиемом нзвгке С++. SQL-cepBep под- 
держивает создание хранимвгх процедур на управлнемом коде. При первом получе- 
нгш запроса на ввшолнение хранимои процедурБг на управлнемом коде SQL-cepBep 
загружает CLR. Хранимвге процедурвг вбшолннготсн в собственном загцигценном 
домене, что не позволнет им нарушитв работу сервера базвг даннБгх. 

Зто просто замечателБнал функционалБностБ! ВедБ разработчики могут вкгбиратБ 
ИЗБ 1 К программировангш длл создангш хранимвгх процедур. ХранимБге процедурБг 
могут исполБЗОватБ в своем коде обвектБг с силбнои типизациеи. Кроме того, код 
компилируетсн JIT -компиллтором в машиннвги код и вБшолннетсл, а не интерпре- 
тируетсл. Также разработчикам таких процедур доступнБг все типбг, определеннБге 
в библиотеке FCL или лгобои другои сборке. В резулвтате разработка хранимБгх 
процедур значителБно упрогцаетсн, а приложенгш работагот намного бБгстрее. Что 
егце нужно программисту длн счастни? 


Будуицее и мечтм 

В будугцем в обвганБгх «офиснБ1Х» приложенгшх, таких как редакторБг и злектрон- 
нБге таблицБг, полБЗОватели смогут ввгбиратБ нзбгк программировангш длн создангш 
макросов. Зти макросвг обеспечат доступ к лгобвш сборкам и типам, поддержи- 
вагогцим CLR. Они будут компилироватБСи и позтому бнгстро вбшолннтбси, и, что 
самое важное, — вбшолнитбсн в загцигценном домене, избавлии полвзователеи от 
многих непргштнБгх неожиданностеи. 
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НетривиалБное управление хостингом 

В зтом разделе рассматриваготсл более сложнме вопросм хостинга CLR. И хочу 
датБ предоставление о всеи широте возможностеи CLR. Если тема зтого раздела 
вас заинтересует, л рекомендуго обратитћсн к другои литературе по даннои теме. 

Применение управллемого кода 

Класс System . AppDomainManagen позволиет хосту меннтБ заданное по умолчаниго 
поведение CLR при помогци управлнемого кода. Конечно, зто упрогцает реализациго 
хоста. Вам требуетсл толбко определитБ собственнг.1и класс, производнми от System . 
AppDomainManager, переопределив все необходимме виртуалг>нме методм. Далее 
зтот класс надо скомпоноватБ в отделБнуго сборку и установитБ ее в глобалБнми 
кзш сборок (GAC), предоставив еи тем самћш полное доверие. 

Затем нужно заставитв CLR исполБЗОватБ свои класс, производнБиг от 
AppDomainManager. Зто лучше всего сделатв, создав обвект AppDomainSetup и ини- 
циализировав его своиства AppDomainManagerAssembly и AppDomainManagerType 
типа String. Своиству AppDomainManagerAssembly присваиваетсн строка со строгим 
именем сборки, определнгогцеи ваш класс, производнвш от класса AppDomainManager. 
Своиству же AppDomainManagerType присваиваетсн полное имн зтого класса. Кроме 
того, своиству AppDomainManager с помогцбго злементов appDomainManagerAssembly 
и appDomainManagerType можно присвоитв конфигурационнБнг ХМК-фаил ваше- 
го приложенгш. Также собственнвш хост может отправитБ запрос к интерфеису 
ICLRControl и вБгзватБ его своиство SetAppDomainManagerType, передав туда 
идентификатор установленнои в GAC сборки и ими класса, производного от 
AppDomainManager 1 . 

Теперв поговорим о функцинх класса, производного от AppDomainManager. Он 
позволнет хосту сохранитв контролБ, даже когда надстроика пБгтаетсл создатБ 
собственнБш домен. При зтом обвект, производнБги от AppDomainManager, может 
редактироватБ параметрБг загцитБг и конфигурировангш. Кроме того, он в состоннгш 
помешатв созданиго нового домена или вернутв ссбглку на уже сугцествугогцгш. Ког- 
да новбги домен уже создан, CLR формирует в нем новбги обвект, производнБги от 
AppDomainManager. Он также может редактироватк параметрБг конфигурировангш, 
контекст вБгполненгш между потоками и разрешенин, предоставленнБге сборке. 

Разработка надежннх хост-приложении 

Хост может указатБ CLR, какие деиствгш следует предприниматБ при сбое в управ- 
лнемом коде. Вот несколвко примеров (от наименее до наиболее сервезного): 


1 Конфигурацшо класса AppDomainManager можно вбгполнитб также при помогци пере- 
меннБгх окруженин и параметров реестра, но зти механизмвг более громоздки и применнтБ 
их имеет смбгсл разве что в некоторвгх тестоввгх сценарилх. 
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□ CLR может прерватБ поток, если тот вБшолннетсл слишком долго или долго не 
возврагцает управление (детали см. в следугогцем разделе). 

□ CLR может ввшрузитћ домен. При зтом закроготсл все потоки зтого домена, 
а проблемнвш код будет вБггружен. 

□ CLR может отклгочитбсл. При зтом прекрагцаетсл вБшолнение лгобого кода 
в процессе, но неуправлиемому коду работатв разрешено. 

□ CLR может вбшти из Wi n(lo\vs-ii роцесса. При зтом сначала закрншаготсл все 
потоки и вБшружаготсл все домеш.1 — вбшолннготси операции очистки, после 
чего процесс закркшаетсл. 

CLR может завершитБ поток или домен как корректно, так и принудителБно. 
Корректное завершение предусматривает ввшолнение кода очистки. Иначе говорн, 
вБшолннетсч код в блоках f inally и ввгоБшаготси методБ1 финализации обвектов. 
При принудителБном завершении код очистки игнорируетсл. При корректном за- 
вершении, в отличие от принудителвного, не удастсн закрр.гп. поток в блоках catch 
и f inally. Поток, вбшолннгогции неуправлнемБги код или находигцииси в критиче- 
скои области (Critical Execution Region, CER), завершитв вообгце нелвзи. 

Хост может установитБ так назБшаемуго политикурасширенил (escalation policy), 
определив тем самвгм поведение CLR при сбонх управлнемого кода. Например, SQL- 
сервер определлет, что должна делатв среда CLR при понвлении необработанного 
исклгоченгш во времн ввшолненгш управлчемого кода. Когда в потоке возникает 
необработанное исклгочение, CLR сначала пвгтаетсл корректно завершитк поток. 
Если поток не закрБшаетси за определенное времн, CLR ш.пастси переити от кор- 
ректного к принудителБному завершениго потока. 

В болБшинстве случаев происходит именно так. Однако длл потоков из критиче- 
скоп области (critical region) деиствует другал политика. Поток, находнгциисл в кри- 
тическои области, блокируетсл в рамках синхронизацгш потоков, причем разбло- 
кироватБ его должен тот же самнш поток, например, тот, что вБгзвал метод Monltor . 
Enten, метод WaitOne типа Mutex или один из методов AcquireReaderLock или 
AcquireWriterLock типа Reader^riterLock 1 . Ожидание методов AutoResetEvent, 
ManualResetEvent или Semaphore не указвшает на пребБшание потока в критическои 
области, потому что другои поток может освободитв зтот обвект синхронизации. 
Когда поток находитсл в критическои области, CLR полагает, что он работает 
с даннБши, совместно исполвзуемБши несколБкими потоками того же домена. Зто 
и естБ наиболее вероитнаи причина блокировангш потока. При работе с обгцими 
даннБши простое завершение потока нвлиетсл неудачнвш решением, потому что 
к даннБш могут обрагцатБСн другие потоки. Даншле же уже поврежденБг. В итоге 
мб 1 получаем непредсказуемое поведение домена и бреши в системе безопасности. 


1 При лгобом блокировании внзнваготсл методвг BeginCriticalRegion и EndCriticalRegion 
класса Thread, показнвагогцие момент входа в критическуго областв и вг>гхода из нее. При не- 
обходимости вн тоже можете ими восполг>зоватг>сл. Такал необходимостБ обично возникает 
при взаимодеиствии с неуправллемвгм кодом. 
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Позтому, когда в потоке в критическои области возникает необработанное 
исклгочение, CLR сначала пмтаетсл свести исклкзчение к корректнои вмгрузке 
домена в попмтке избавитБСн от всех исполБзуемБ1х потоков и обвектов даннБ1х. 
Если домен не вБ 1 гружаетсл за указанное времн, CLR переходит от корректнои 
к принудителБнои вБ1грузке. 


Возвра1цение потока в хост 

06 б 1 чно хост-приложение пБ1таетсл контролироватБ собственнБ 1 е потоки. В ка- 
честве примера рассмотрим сервер базБ 1 даннБ 1 х. При поступлении запроса поток 
принимает его и пересБшает другому потоку, которкш и должен сделатн нужнуго 
работу. Может случитнси, что второму потоку придетсл вбшолнитб код, созданнБпт 
и протестированнБш не командои разработчиков сервера, а сторонними програм- 
мистами. Например, он может вбшолнитб хранимуго процедуру, написаннуго на 
управлнемом коде. Что замечателвно, сервер базБ 1 даннБ 1 х делает зто в собственном 
домене приложении, работагогцем с максималвнБши ограниченгшми безопасности. 
В резулБтате хранимаи процедура не может обратитнсн к обвектам за пределами 
собственного домена, а также получитв доступ к ресурсам, к которкш коду обра- 
гцатБСн запрегцено, например к дисковбш фаилам или буферу обмена. 

Но что если код хранимои процедурБг воидет в бесконечнвпг цикл? То естк сервер 
базвг даннБгх «отдает» один из своих потоков длл ввшолненгш кода хранимои про- 
цедуркг, но поток не возврагцает управление. Сервер оказвгваетсн в опасном положе- 
нии, и его поведение становитсн непредсказуемвш. Например, может силбно упастн 
производителБностБ. Может, серверу стоит создатв дополнителБНБге потоки? Но 
на зто вам потребуготсн дополнителБнвге ресурсБг (например, место в стеке), кроме 
того, и зти.м потокам ничто не может помегнатБ застрнтБ в бесконечном цикле. 

Длн регненгш подобнвгх проблем хосту предоставлнетсл право завергненгш по- 
тока. На рис. 22.3 показана типичнаи архитектура хост-приложенгш, пБгтагогцегосн 
решитБ проблему внгшедшего из-под контролн потока. Вот как зто происходит 
(номера операции соответствугот числам на рисунке). 

1. Клиент направлиет запрос на сервер. 

2. Поток сервера принимает запрос и пересвшает его потоку из пула длл вбшол- 
ненгш работБг. 

3. Поток из пула принимает клиентскгш запрос и вБшолннет довереннБги код, 
то естБ код, созданнБш в компангш, в которои создано и протестировано само 
хост-приложение. 

4. Довереннвш код входит в блок try и вБгзвшает из него другои домен (исполБзун 
тип, производнБш от MarshalByRefObject). Зтот домен содержит код (напри- 
мер, хранимуго процедуру), созданнкш и протестированнБш сторонними раз- 
работчиками. 

5. Хост фиксирует времи полученин исходного клиентского запроса. Если сто- 
роннгш код не отвечает клиенту за определенное администратором времн, хост 
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вмзмвает метод Abont типа Thread, требуи от CLR остановитБ поток из пула 
и вмнуждан вмдатБ исклгочение ThreadAbortException. 

6. На зтом зтапе поток пула начинает завершение, вмзмвал блоки finally, чтобм 
вмполнитб код очистки. В итоге поток возврагцаетсн в домен. Так как программа- 
заглушка вмзвала стороннии код из блока try, в неи имеетси и блок catch, 
которми перехватмвает исклгочение ThreadAbortException. 

7. В ответ на перехват исклгоченин ThreadAbortException хост вмзмвает метод 
ResetAbort типа Thread. Зачем зто нужно, н о6ђиснго чутЂ позже. 

8. Хост отправлиет информациго о сбое клиенту и возврагцает поток в пул, чтобм 
его можно бмло снова задеиствоватБ дли обслуживанин клиентских запросов. 




Рис. 22.3. Возвраш,ение хостом контролл надпотоком 

Пропснго некоторме непонитнме места зтои архитектурм. Во-первмх, метод 
Abort типа Thread вмполннетсн асинхронно. Он отмечает целевои поток флагом 
AbortRequested гг немедленно возврагцает управление. Обнаружив завершение по- 
тока, исполннгогцан среда пмтаетсл перенести зтот поток в безопасное место (safe 
place). Исполнпгогцан среда считает, что поток находитсл в безопасном месте, если 
его можно (по ее мнениго) остановитћ без риска серћезнмх последствии. Поток на- 
ходитси в безопасном месте, если ввгполннет управлнемуго операциго блокировки, 
например бездеиствует или «спит». Перемегцение в безопасное место осугцествли- 
етсн путем захвата (см. главу 21). Поток не считаетси находигцимси в безопасном 
месте, если он ввгполннет конструктор класса типа, код блока catch или f inally, 
код в критическои области или неуправлиемБш код. 

Как толбко поток оказБгваетсн в безопасном месте, исполнпгогцаи среда об- 
наруживает у него флаг AbortRequested и заставлнет его ввгдатБ исклгочение 
ThreadAbortException. Если исклгочение не перехватБгваетсн, оно остаетсн необра- 
ботаннвгм, вБгполннготсн все блокгг finally и поток корректно завершаетси. В отлгг- 
чие от всех прочих, оставшисв необработаннБгм, исклгочение ThreadAbortException 
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не приводит к остановке приложенин. Исполннклцаи среда поглотцает его, и поток 
завершаетси, но приложение и все оставшиесл его потоки продолжагот работу. 

В рассматриваемом примере хост перехватмвает исклгочение ThreadAbont- 
Exception, получан возможностб снова получитБ контролБ над потоком и возвратитк 
его в пул. Однако остаетсл вопрос: что может помешатв стороннему коду перехватнтБ 
нсклгочение ThreadAbort Exception, что 6 б 1 сохранитБ за собои контролБ над потоком? 
У CLR к данному исклгочениго особое отношение. Даже если код перехватБшает ис- 
клгочение ThreadAbortException, CLR в конце блока catch автоматически повторно 
его генерирует. 

В свнзи с зтои особенноствго CLR возникает вопрос: если CLR повторно генери- 
рует исклгочение ThreadAbortException в конце блока catch, как же хосту удаетсн 
перехватитв зто исклгочение и восстановитБ контролБ над потоком? В блоке catch 
хоста естБ вбгоов метода ResetAbort типа Thread. Именно он запрегцает CLR повторно 
генерироватБ исклгочение ThreadAbortException в конце каждого блока catch. 

Тогда снова возннкает вопрос: а что может запретитв стороннему коду перехватитБ 
исклгочение ThreadAbortException и самому вБ13ватБ метод ResetAbort типа Thread? 
К счастБГО, длл вБ130ва зтого метода у ввгоБшагогцеи программБ1 должно 6 бгтб разреше- 
ние SecurityPermission с флагом ControlThread, имегошим значение true. Создавал 
домен длл кода сторонних разработчиков, хост не предоставлнет такое разрешение, 
а, значит, такои код не сможет сохранитв за собои контролБ над его потоком. 

Должен заметитБ, что брешБ в системе безопасности в данном случае все-таки воз- 
можна: когда поток раскручнвает исклгоченне ThreadAbortException, стороннии код 
может вбшолнитб блоки catch и f inally, содержагцие код с бесконечнБш циклом, не 
позволлгогцим хосту вернутв контролБ над потоком. Зта проблема решаетсл при по- 
могци обсуждавшеисл ранее политики расширенгш. Если останавливаемБш поток не 
завершаетсл за разумное времн, CLR может переити от корректнои к принудителБнои 
остановке, принудителвнои вБггрузке домена, отклгочениго CLR или уничтожениго 
процесса. Следует также заметитк, что стороннии код может перехватитБ исклгочение 
ThreadAbortException и вброситк в блоке catch какое-то другое исклгочение. Если 
оно перехватБшаетси, в конце блока catch CLR автоматически повторно ввгдаст ис- 
клгочение ThreadAbortException. 

Болбшинство сторонних программ не представлнет угрозвг — просто с точки 
зренгш хоста они тратлт на решенне своеи задачи слишком много времени. Обвшно 
блоки catch и finally содержат оченв немного кода, вБшолннемого бнгстро без 
каких-либо бесконечнБгх циклов или «долгоиграгогцих>> операции. Позтому врнд ли 
вам потребуетсл политика расширенгш длл возврагценгш управленггн потоком хосту. 

Кстатгт, у класса Thread еств два метода Abort: одггн без параметров, а второи 
с параметром Ob ject, в котором можно передатв лгобои обвект. Перехватггв ггсклго- 
ченгге ThreadAbortException, код может запроситв свое предназначенное толбко 
длл чтенгш своиство ExceptionState, которое вернет обвект, переданнБги в качестве 
параметра. Зто позволлет потоку, ввгзвавшему метод Abort, передатв дополнггтелБ- 
нуго ггнформацггго коду, перехватггвшему ггсклгочение ThreadAbortException. Хост 
может ггсполБЗОватв зто длл ггнформггрованггн собственного перехватБгвагогцего кода 
о прггчггне остановкгг потока. 
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В зтои главе рассказано о том, как находитБ информацикз о типах, создаватБ их 
зкземплирБ 1 и обеспечиватБ доступ к их членам, несмотри на то что во времи ком- 
пилнции об зтих типах ничего не известно. Сведенин, приведеннвге в зтои главе, 
обвгчно нужнБг длн созданин динамически расширнемБгх приложении, то естБ таких, 
дли которкгх одна компанин создает хост-приложение, а другие — подклтчаемие 
компоненти (add-ins), которнге расширигот функционалБностБ хоста. ТестироватБ 
совместнуго работу хоста и подклгочаемвгх компонентов невозможно, так как по- 
следние создаготси разнвши компаниими, причем, как правило, уже после ввгпуска 
хост-приложенгш. Вот почему хосту приходитсл самостоителБно находитн под- 
клгочаемБге компонентБг во времи вБгполненгш. 

Динамически расшириемое приложение может исполБЗОватБ хостинг CLR 
и доменБг приложении, как описано в главе 22. Хост ввшолннет код подклгочаемБгх 
компонентов в отделвнвгх доменах приложении с собственнБгми параметрами за- 
гцитбг и конфигурировангш. Хост также может ввггрузитБ подклгочаемБш компо- 
нент, вБггрузив домен приложении, в котором он ввшолннетсл. В конце главкг мбг 
поговорим о том, как задеиствоватв все зти механизмвг, — вклгочаи хостинг CLR, 
доменвг приложении, загрузку сборок, обнаружение типов, создание зкземплиров 
типов и отражение, — дли создангш надежного, безопасного и динамически рас- 
ширнемого приложешш. 

ПРИМЕЧАНИЕ 

В .NET Framevvork версии 4.5 компаниа Microsoft ввела новми API отраженил. У старо- 
го API бмло много недостатков. Например, он плохо поддерживал LINQ, встроеннме 
политики бмли некорректнБ 1 ми длл некотормх лзмков, иногда он принудителино 
загружал ненужнме сборки, в целом 6bm слишком сложнмм и предлагал решенил 
длл задач, которме краине редко встречалиси на практике. В новом API все зти не- 
достатки устраненм. С другои сторонн, в .NET 4.5 HOBbin API отраженич обладает 
менишеи полнотои, чем старми API. С HOBbiM API и некотормми методами рас- 
ширенил (из класса System.Reflection.RuntimeReflectionExtensions) можно сделати 
все необходимое. В будуидих версилх .NET Framevvork в новми API будут вклкзченм 
дополнителинме методвг 

Конечно, длп HacTO^bHbix приложении старми API продолжает поддерживатисл, так 
что перекомпилчцил не нарушит совместимости суш,еству 10 ш,его кода. Тем не менее 
в разработках, ориентированнмх на будуидее, рекомендуетсл исполизоватв новми 
API, позтому он будет подробно рассматриватисл в зтои главе. В приложенилхУ\/1п- 
dows Store (в котормх проблема совместимости отсутствует) исполвзование нового 
API обчзателвно. 
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Загрузка сборок 

Как вм уже знаете, когда JIT -компилнтор генерирует IL -код метода, он «смотрит», 
на какие типм ес п, ссмлки в IL -коде. Далее во времи вмполненин Ј1Т-компилнтор 
по таблицам метаданнмх TypeRef и AssemblyRef вмисниет, в какои сборке опреде- 
лен упоминаемми тип. Записћ таблицм AssemblyRef содержит все части строгого 
имени сборки. JIT -компилитор собирает все зти части — ими (без расширении 
и пути), версшо, регионалБнме стандартм и открмтми к. поч — в строку, а затем 
пмтаетси загрузитБ сборку с таким именем в домен приложении (если она егце не 
загружена). Если загружаетси сборка с нестрогим именем, идентификационнаи 
информации представлиет собои то./њко ими сборки (без версии, регионалБнмх 
стандартов и открмтого клгоча). 

CLR пмтаетсл загрузитБ зту сборку, испо./њзуз статическии метод Load класса 
System . Reflection . Assembly. Зтот метод описан в открмтои документации, его 
можно вмзмватБ дли нвнои загрузки сборки в свои приложенин. Он представлиет 
собои CLR -зквивалент \¥1п,32-фупкнии LoadLibrary. Метод Load класса Assembly 
сугцествует в песко. п.ких перегруженнмх версиих. Вот прототипм наиболее по- 
пулнрнмх из них: 

public class Assembly { 

public static Assembly Load(AssemblyName assemblyRef); 

public static Assembly Load(String assemblyString); 

// Менее популнрние перегруженнме версии не показанп 

} 

Внутреннии код Load заставлиет CLR примспитк к сборке политику привизки 
версии с перенаправлением и шцет нужнуго сборку сначала в глоба. њпом кзше 
сборок (GAC), а затем последователБно в базовом каталоге приложении, каталогах 
закрмтмх путеи и каталоге, указанном в злементе codeBase конфигурационного 
фаила. Если методу Load передаетси сборка с нестрогим именем, он не примениет 
к неи политику, и CLR не шцет ее в GAC. Наидл искомуго сборку, Load возврагцает 
ссмлку на обвект Assembly, представлнгогции загруженнуго сборку. Если указаннан 
сборка не наидена, понвлиетси исклгочение System. 10. FileNotFoundException. 

ПРИМЕЧАНИЕ 

В чрезвв 1 чаино редких ситуацизх может потребоватвсз загрузитв сборку, скомпоно- 
ваннук) дпн определеннои версии MicrosoftWindows. В зтом случае при определении 
идентификационнои информации сборки можно указаљ сведенил об архитектуре 
процесса. Например, если в GAC хранлтсл неитралвнал и специализированнал (х86) 
версии сборки, CLR предпочтет специализированнукз версинз (см. главу 3). Однако 
можно заставиљ CLR загрузитв неитралвнук) версииз, передав в метод Load класса 
Assembly такукз строку: 

"SomeAssembly, Version=2.0.0.0j Culture=neutral , 
PublicKeyToken=01234567890abcdej ProcessorArchitecture=MSIL" 

Ha момент написанил зтои книги CLR поддерживает четнре возможнмх значенил 
параметра ProcessorArchitecture: MSIL (Microsoft IL), x86, IA64 и AMD64. 
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ВНИМАНИЕ 

Метод Load есљ и у обвекта System.AppDomain. В отличие от одноименного метода 
обЂекта Assembly, он чвлчетсл зкземпллрнЂ 1 м методом, позволлкхцим загружатЂ 
сборку в домен приложении. Зтот метод создан дли неуправллемого кода, позволлл 
хосту загрузити сборку в определеннЂш домен приложении. Разработчикам управ- 
ллемого кода лучше его избегатЂ, и вот почему. При вмзове методу Load обЂекта 
AppDomain передаетсл строка, идентифициру 101 дал сборку. Зтот методзатем приме- 
нлет политику и иш,ет сборку в o6bi4Hbix местах: на полнзователиском жестком диске 
или в базовом каталоге. Вспомните, что с каждмм доменом приложении свлзанв! 
параметрн конфигурации, определлкзидие правила поиска сборки длл CLR. Так вот, 
при загрузке сборки CLR будет руководствоваљсл конфигурациеи заданного, а не 
Bbi3biBaiomero домена приложении. 

Однако метод Load обЂекта AppDomain возвраидает ссЂшку на сборку. В силу того, 
что класс System.Assembly не нвллетса потомком System.MarshalByRefObject, о6ђ- 
ектсборки возвраидаетсл вЂ 1 зи 1 вакдидемудомену приложении путем продвиженил по 
значеникз. Но Tenepb длл поиска и загрузки сборки CLR задеиствует параметри bw- 
зшвакнцего домена приложении. Если сборку не удаетсл наити при помоиди политики 
Bbi 3 biBaiOLpero домена приложении или в заданнв1х им каталогах поиска, генерируетсл 
исклкзчение FileNotFoundException. Такал ситуацил o6bi4HO нежелателина, позтому 
следует избегати метода Load обЂекта System.AppDomain. 


В болЂшинстве динамически расширнеммх приложении метод Load обвекта 
AppDomain нвлнетси предпочтителБнмм механизмом загрузки сборки в домен при- 
ложении, но он требует наличии всех частеи, идентифициругогцих сборку. Часто 
разработчики создагот инструментм или утилитм (такие, как ILDasm.exe, PEVerify. 
ехе, CorFlags.exe, GACUtil.exe, SGen.exe, SN.exe и XSD.exe), которме определеннмм 
образом обрабатмвагот сборку. Все они принимагот параметр команднои строки, 
задагогции путБ (с расширением) к фаилу сборки. 

Что6бд загрузитћ сборку с указанием пути, вБдзовите метод LoadFrom класса 
Assembly: 

public class Assembly { 

public static Assembly LoadFrom(String path); 

// Менее популлрнне перегруженнме версии не показанм 

} 

Код LoadFrom сначала вмзмвает метод GetAssemblyName класса System. 
Reflection . AssemblyName, которБш открћшает указаннћш фаил, находит записБ 
таблицБг метаданнћгх AssemblyRef, извлекает идентификационнуго информациго 
сборки и возврадцает ее в обЂекте System . Reflection . AssemblyName (фаил при зтом 
закрћшаетсн). Затем LoadFrom вБгзћшает метод Load класса Assembly, передаван ему 
обвект AssemblyName. На зтом зтапе CLR применлет политику перенаправлешш 
версии и игцет в определеннвгх местах соответствугогцуго сборку. Наидл сборку, 
Load загружает ее и возврагцает обЂект Assembly, представлнгогции загруженнуго 
сборку; именно его возврагцает LoadFrom. Если методу Load неудаетсн наити сборку, 
LoadFrom загружает сборку по пути, переданному в качестве параметра в LoadFrom. 
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Лсно, что если сборка с теми же идентификационнмми даннмми уже загружена, 
LoadFrom просто возврагцает обвект Assembly, представлнкдции уже загруженнуго 
сборку. 

Кстати, методу LoadFrom можно передатБ в качестве параметра URL -адрес: 
Assembly а = Assembly . LoadFrom(@"http://Wintellect . com/SomeAssembly.dll"); 

При получении URL -адреса среда CLR загружает фаил, устанавливает его 
в загрузочнми кзш полБЗОвателн и уже из него загружает фаил. Система должна 
6 мтб подклгочена к Интернету, иначе произоидет исклгочение. Однако если фаил 
уже бмл загружен в icjiii ранее, а браузер Internet Explorer настроен на работу в ав- 
тономном режиме (команда Work Offline (РаботатБ автономно) в менго File (Фаил)), 
будет исполћзован фаил из lonia, и исклгочениене возникнет. Такжеможно вмзватБ 
метод Unsaf eLoadFrom, которми загрузит уже загруженнуго веб-сборку, игнорируи 
некоторме параметрм загцитм. 

ВНИМАНИЕ 

На однои машине могут находитБС^ разнме сборки с одинаковои идентификационнои 
информациеи. Так как LoadFrom внзмвает Load, может оказатг,сл, что CLR загрузит не 
указаннми, а другои фаил, что чревато непредсказуеммм поведением. Настолтелв- 
но рекомендуетсч при каждои компоновке сборки изменатв номер редакции — так 
обеспечиваетсл строгал индивидуалвноств идентификационнои информации всех 
сборок, а значит, вмзов метода LoadFrom не принесет неожиданностеи. 


Конструкторм графического интерфеиса и другие инструментм Microsoft Visual 
Studio обмчно исполБзугот метод LoadFile класса Assembly. Зтот метод может 
загрузитБ сборку по лгобому пути и его можно задеиствоватБ дли загрузки сборки 
с идентичнБши параметрами в единственнвш домен приложении. Зто удобно 
в случае, когда при помогци конструктора или другого инструмента 6 бши внесенБг 
измененин в графическии интерфеис приложенгш, а затем зто приложение 6 бшо 
собрано заново. При загрузке LoadFile среда CLR не разрешает зависимости авто- 
матически, позтому ваш программнћш код должен 6 бгтб зарегистрирован в со6бгтгшх 
AssemblyResolve и иметћ ивно загруженнвге методБг обратнБгх вбгзовов собвгтии 
всех зависимБгх сборок. 

Если вб 1 создаете инструмент, которнпг просто анализирует метаданннге сборки 
с исполБЗОванием отраженгш (об зтом — чутв позже), не вбгполнжг никакого кода сбор- 
ки, лучше всего длч загрузки сборки задеиствоватвметод ReflectionOnlyLoadFrom 
или, в некоторвгх редких случанх, метод ReflectionOnlyLoad класса Assembly. Вот 
прототипБг обоих методов: 

public class Assembly { 

public static Assembly ReflectionOnlyLoadFrom(String assemblyFile); 

public static Assembly ReflectionOnlyLoad(String assemblyString); 

// Менее популлрние перегруженнме версии не показанн 

} 


640 Глава 23. Загрузка сборок и отражение 

Метод ReflectionOnlyLoadFrom загружает указаннши фаил, не получал ин- 
формацшо строгого имени сборки и не вмполннн поиск фаила в GAC или где-либо 
emc. Метод ReflectionOnlyLoad вмполниет поиск указаннои сборки в GAC, ба- 
зовом каталоге приложенгш, частнмх каталогах и каталоге, указанном в злементе 
codeBase. Однако в отличие от Load зтот метод не примениет политику версии, 
позтому не предоставлиет гарантии, что будет загружена именно та сборка, которан 
ожидаласш Если вм хотите самостоителБно применитБ политику версии к сборке, 
можно передатБ строку с идентификационнои информациеи в метод AppDomain 
класса ApplyPolicy. 

При загрузке сборок методом ReflectionOnlyLoadFrom или ReflectionOnlyLoad 
среда CLR запрегцает ввшолнение какого-либо кода сборки, а при попБггке вбг- 
полннтб код генерирует исклгочение InvalidOperationException. Зти методнг 
позволнгот инструменту загружатв сборки с отложеннБгм подписанием, сборки 
дли процессора другои архитектурБг, а также сборки, дли загрузки которнгх нужнБг 
особБге разрешении. 

Часто при исполБЗОвании отраженгш длл анализа сборки, загруженнои одним 
из указаннвгх двух методов, код должен зарегистрироватв метод обратного внгзова 
на собвгтие ReflectionOnlyAssemblyResolve класса AppDomain, чтобвг вручнуго за- 
гружатв произволБНБге сборки, задаваемБге клиентом (при необходимости вБгзБгван 
метод ApplyPolicy класса AppDomain); CLR не делает зтого автоматически. Будучи 
вБгзваннБгм, метод обратного внгзова должен ввгзватБ метод Ref lectionOnly LoadFrom 
или Ref lectlonOnlyLoad класса Assembly, чтобкг ивно загрузитв указаннуго сборку 
и вернутБ ссБшку на нее. 

ПРИМЕЧАНИЕ 

Мена часто спрашивакзт о поридке вБ 1 грузки сборок. К сожаленикз, CLR не позволпет 
вБ 1 гружатБОтделБНБ 1 есборки. Если 6bi зтобБшотак, возможна бмлабм ситуацил, когда 
поток возврагцает управление из метода в код вмгруженнои сборки, и в резулБтате 
происходит сбои приложенил. Однако среда CLR предназначена в первукз очередБ 
на повБ 1 шение надежности и безопасности, а подобнме сбои лвно противоречат 
зтим целлм. Чтобм вмгрузитБ сборку, придетсл вмгрузити веси домен приложении, 
в котором она находитсл. Подробнее см. главу 22. 

КазалосБ бм, сборки, загруженнБ 1 е методом ReflectionOnlyLoadFrom или 
ReflectionOnlyLoad, должно 6biTb разрешено вмгрузитм В конце концов, веди код 
зтих сборок нелизл вмполнчтш Однако CLR не разрешает вмгрузку сборок, загру- 
женнмх одним из зтих методов, по тои простои причине, что после загрузки сборок 
Bbi всегда сможете исполвзоваш отражение длл созданил обнектов, ссвша10ш,ихсл 
на метаданнме, определеннме в зтих сборках. При вмгрузке сборки потребовалоси 
6bi каким-то образом сделати обБектм недеиствителБнмми, но отслеживание всех 
зтих свлзеи — слишком сложнал и ресурсоемкач задача. 


Многие приложенгш содержат ЕХЕ-фаилнг, зависимБге от многих DLL -фаилов. 
При установке зтих приложении также должнбг устанавливатБСи все фаилвг. Од- 
нако обнгчно практикуетси установка единственного ЕХЕ-фаила. В зтом случае 
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в первуго очередБ идентифицируите все DLL -фаилм, от котормх зависит ваш 
ЕХЕ-фаил и которме не нвлнготсл часп.к) платформм Microsoft .NET Framework. 
Затем добавше зти DLL -фаилм к вашему проекту в Visual Studio и длп каждого 
добавленного DLL -фаила откроите окно своиств и измените значение Build Action 
на Embedded Resource. Зто деиствие даст указание компилнтору C# добавитБ DLL- 
фаилм в ЕХЕ-фаил, которми в конечном итоге и будет устанавливатБСн. 

На зтапе вБшолненин программћг среда CLR не сможет наити зависимБге сборки, 
что может вБгзватБ проблемБк Длн решенгш зтих проблем зарегистрируите методнг 
обратного вБгзова при помогци собвтш ResolveAs sembly при инициализации вашего 
приложенгш. ПрограммнБш код должен вБгглндетБ примерно так: 

private static Assembly ResolveEventHandler(Object sender, ResolveEventArgs args) { 
String dllName = new AssemblyName(args.Name).Name + ".dll"; 

var assem = Assembly.GetExecutingAssembly(); 

String resourceName = assem.GetManifestResourceNames().FirstOrDefault(rn => 
rn.EndsWith(dllName)); 

if (resourceName == null) return nullj 

// Not found, maybe another handler will find it 
using (var stream = assem.GetManifestResourceStream(resourceName)) { 

Byte[] assemblyData = new Byte[stream.Length]; 
stream.Read(assemblyDataj <д, assemblyData.Length); 
return Assembly.Load(assemblyData); 

} 


При первом ввгзове в потоке метода, ссБглагогцегосл на тип, зависнгции от 
DLL -фаила, возникнет собвгтие AssemblyResolve, и показаннвпг программнБш 
код обратного вкгзова наидет встроеннвш DLL -фаил и загрузит его путем внгзова 
перегруженного метода Load, у которого в качестве аргумента будет исполБЗОватБСн 
Byte [ ]. И хотл мне нравитсл прием встраивангш зависимвгх DLL в другие сборки, 
следует помнитб, что он увеличивает обвем памнти, исполвзуемои приложением 
во времл вБгполненгш. 


Исполвзование отраженил длл созданил 
динамически расширчеммх приложении 

Как вам известно, метаданнвге — зто набор таблиц. При построенгш сборки или мо- 
дулн компшштор создает таблицБг определении типов, полеи, методов и т. д. В про- 
странстве имен System . Ref lection еств несколБКО типов, позволнгогцих писатБ код 
разбора зтих таблиц. На самом деле типбг из зтого пространства имен предоставлнгот 
обБектнуго моделБ длн работБг с метаданнБгми сборки или модули. 

Типбг, составлнгогцие зту обБектнуго моделк, позволнгот легко перечислитБ все 
ТИПБ1 из таблицБ! определении типов, а также получитБ длн каждого из них базовБпг 
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тип, интерфеисм и ассоциированнме с ним флаги. Осталћнме типм из пространства 
имен System. Reflection дагот возможностб запрашиватБ полн, методм, своиства 
и собмтин типа путем разбора соответствугогцих таблиц метаданнмх. Можно узнатБ, 
какими атрибутами (см. главу 18) помечена та или инал сугцностБ метаданнБгх. Естб 
даже классБц позволчгогцие определитв указаннБге сборки и методкг и возврагцагогцие 
в методе баитоввш IL -поток. Располаган зтои информациеи, можно легко создаватв 
программБц сходнБге с программои ILDasm.exe компании Microsoft. 

ПРИМЕЧАНИЕ 

Нужно иметБ в виду, что некоторме типм отражениз и частБ их членов созданБ! специ- 
алБно длл разработчиков, пишуцдих компилаторм длч CLR. Прикладнше разработчики 
обмчно не исполБзукзт зти типб 1 и члени. В документации к библиотеке FCL не сказано 
четко, какие Tnnbi предназначени длл разработчиков компилпторов, а какие — длл 
разработчиков приложении, ноесли понимаљ, что некоторметипБ! и членм отраженил 
предназначенн «не длл всех», то документацил становитсл более понлтнои. 


В реалБности приложениим редко требуготси типбг отраженгш. Обнгчно отра- 
жение исполБзуетси в библиотеках классов, которвгм нужно пончтб определение 
типа дли предоставленин расширеннои функционалвности. Например, механизм 
сериализации из FCL (см. главу 24) применчет отражение, чтобвг вбшснитб, какие 
по./ш определенБг в типе. Обвект форматировангш из механизма сериализации 
получает значенгш зтих полеи и записвгвает их в поток баитов длл пересвглки по 
Интернету, сохраненгш в фаиле или отправки в буфер обмена. Проектировгцики 
Microsoft Visual Studio исполвзугот отражение, что6бг определитБ, какие своиства 
следует показвгватв разработчикам при размегцении злементов на поверхности 
веб-формвг или формБг Windows Forms во времн ее создании. 

Отражение также применчгот, когда длл решенгш некоторои задачи во времн 
вБгполненгш приложениго нужно загрузитн определеннБги тип из некоторои сборки. 
Например, приложение может попроситк полБЗОвателн предоставитв ими сборки 
и типа, чтобпг hbho загрузитв ее, создатБ зкземплир данного типа и вБгзкгватБ его 
методБг. КонцептуалБно подобное исполБЗОвание отраженич напоминает вбгзов 
\\1п32-фупкции LoadLibrary и GetProcAddress. Часто привнзку к типам и вбгзбг- 
ваемБгм методам, осугцествлнемуго таким образом, назвгвагот поздним свлзиванием 
(late binding) — в отличие от раннего свлзиванил (early binding), примениемого, 
когда требуемвге приложениго типбг и методБг известнБг при компилнции. 


ПроизводителБностБ отраженил 

Отражение — исклгочителБно могцнбги механизм, позволнгогции во времн ввгполне- 
1 1 1 1 и обнаруживатБ гг исполБЗОватБ типбг и их членБг, о которБгх во времн компилнцгги 
ничего не бвгло известно. Но у зтои могци еств два сервезнвгх недостатка. 
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□ При исполдзовании отраженил безопасностБ типов на зтапе компилиции не 
контролируетсл. Так как в отражении активно применнготсл строки, вм тернете 
безопасностБ типов на зтапе компилнции. Допустим, длл поиска типа с именем 
int средствами отраженин исполБзуетсн вмзов Туре. GetType ( "int" ) ; код успеш- 
но компилируетсл, но во времп вмполненип возврашает null, так как с точки 
зренин CLR тип int назмваетсл System . Int32. 

□ Отражение работает медленно. При исполвзовании отраженин имена типов 
и их членм на момент компилнции не известнм — они определиготсн в процес- 
се вмполнешш, причем все типм и членм идентифицируготсл по строковому 
имени. Зто значит, что при отражении постоннно вмполниетсл поиск строк 
в метаданнмх сборки пространства имен System . Ref lection. Часто строковми 
поиск вмполннетси без учета регистра, что дополнителБно замедлнет процесс. 

В обгцем случае вмзов метода или обрагцение к полго или своиству посредством 
отраженин также работает медленно. При исполБЗОвании отраженин перед вмзовом 
метода аргументм требуетсл сначала упаковатБ в массив и инициализироватБ его 
злементм, а потом при вмзове метода извлекатБ аргументБ1 из массива и помегцатв 
их в стек потока. Кроме того, CLR приходитсн провернтв правилБностБ числа и типа 
параметров, переданнвш методу. И наконец, CLR провернет наличие у ввгоБшагогцего 
кода разрешении доступа. 

В силу зтих причин лучше не исполкзоватБ отражение д.;ш обрашенгш к поллм 
или вБгзова методов/своиств. Если bbi пишете приложение, которое динамически 
шцет и создает обБектвг, следуите одному из перечислешшх далее подходов. 

□ Порождаите свои типб 1 от базового типа, известного на момент компилнции. 
Затем, создав зкземплир своего типа во времн ввшолненгш, поместите ссншку 
на него в переменнуго базового типа (вбшолнив приведение типа) и ввшБшаите 
виртуалБНБге методБ1 базового типа. 

□ Реализуите в типах интерфеисБ 1 , известнБШ на момент компилиции. Затем, 
создав зкземшшр своего типа во времн ввшолненгш, поместите ссншку на него 
в переменнуго того же типа, что и интерфеис (вбшолнив приведение типа), и bbi- 
звшаите методБр определеннБге в интерфеисе. 

Ч предпочитаго второи подход, так как в первом случае разработчику невозмож- 
но ввгбратБ базовБш тип, оптималБНБги длл конкретнои ситуации. Хотл методика 
порождешш своего типа от базового лучше в отношении контролн версии, потому 
что вб 1 всегда добавлнете членвг в базоввш тип и наследуете от него свои тип, но не 
можете добавитв членБ1 в интерфеис без принудителвного измененин программного 
кода всех типов, реализугогцих зтот интерфеис, и их повторнои компилиции. 

В лгобом случае л настонтелвно рекомендуго определнтк базовБги тип или интер- 
феис в их собственнои сборке — будет менвше проблем с управлением версинми. 
Подробнее об зтом см. раздел «Создание приложении с поддержкои подклгочаемвгх 


компонентов». 
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Нахождение типов, определенннх в сборке 

Отражение часто исполћзуетсл, чтобм вбшснитб, какие типбг определенБг в сборке. 
Длн полученин зтои информации FCL предлагает несколвко методов. I [аиболсс 
популнрнвш — своиство ExportedTypes класса Assembly. Вот пример кода, которвш 
загружает сборку и вбшодит имена всех определеннвгх в неи otkpbitbix зкспорти- 
рованнБгх типов: 

using System; 

using System.Reflection; 

public static class Program { 
public static void Main() { 

String dataAssembly = "System.Data, version=4.0.0.0, " + 

"culture=neutral, PublicKeyToken=b77a5c561934e089"; 
LoadAssemAndShowPublicTypes(dataAssembly); 

} 

private static void LoadAssemAndShowPublicTypes(String assemld) { 

// Нвнал загрузка сборки в домен приложении 
Assembly а = Assembly . Load(assemld) ; 

// Цикл внполнлетсл длл каждого типа, 

// OTKpbiTO зкспортируемого загруженнои сборкои 
foreach (Туре t in а. ExportedTypes) { 

// Вувод полного имени типа 
Console.WriteLine(t . FullName) ; 

} 

} 

} 

Обт>ект Туре 

Приведеннвш вБнне код перебирает массив обЂектов System.Type. Тип System. 
Туре — отправнан точка длл операции с типами и обЂектами. Он представлиет 
ссБшку на тип (в отличие от определенин типа). 

Как Bbi помните, в System.Object определен открБ 1 твш невиртуалБНБш метод 
GetType. При вБ130ве зтого метода CLR определит тип указанного обљекта и вернет 
ссвшку на его обвект Туре. Посколбку длн каждого типа в домене приложении еств 
ТОЛБКО ОДИН обљект Туре, 4To6bI ВБШСНИТБ, ОТПОСИТСМ ЛИ обЂеКТБ1 к одному типу, 
можно задеиствоватБ операторБ1 равенства и неравенства: 

private static Boolean AreObjectsTheSameType(Object ol, Object o2) { 
return ol.GetType() == o2.GetType(); 

} 


Помимо вБ 130 ва метода GetType класса Object FCL предлагает другие cnoco6bi 
полученгш обЂекта Туре: 

□ В типе System . Туре естк несколЂКО перегруженнмх версии статического метода 
GetType. Все они принимагот тип String. Зта строка должна содержатв полное 
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имн типа (вклгочал его пространства имен). Имена примитивнмх типов, под- 
держиваемме компиллтором (такие, как int, stning, bool и другие типм нзмка 
С#), запрегценм, потому что они ничего не значат длл CLR. Если строка содер- 
жит просто имн типа, метод провериет, определен ли тип с указаннмм именем 
в вмзмвагогцеи сборке. Если зто так, возврагцаетсл ссмлка на соответствугогции 
обвект Туре. 

□ Если в вмзмвагогцеи сборке указаннми тип не определен, провернготси типм, 
определеннвге в MSCorLib.dll. Если и после зтого тип с указаннвгм ггменем 
наити не удаетсн, возврагцаетси null или генерируетси исклгочение System. 
TypeLoadException — все зависит от того, какаи перегруженнаи версгш метода 
GetType вмзмваласБ гг какие еи передавалисБ параметрм. В документации на 
FCL естг> исчерпБгвагогцее описание зтого метода. 

В GetType можно передатБ полное имн типа с указанием сборки, например: 

"System.Int32j mscorlib, Version=2.0.0.0, Culture=neutralj 
PublicKeyToken=b77a5c561934e089" 

B зтом случае GetType будет искатБ тип в указаннои сборке (и при необхо- 
димости загрузит ее). 

□ В типе System . Туре еств статическии метод Ref lectionOnlyGetType. Зтот метод 
ведет себн так же, как толбко что описаннБш метод GetType, за исклгочением того, 
что тип загружаетси толбко длл отраженин, но не дли вБгполненич кода. 

□ В типе System . TypeInfo естк зкземплчрнБге методБг DeclaredNestedTypes 
и GetDeclaredNestedTypes. 

□ В типе System.Reflection.Assembly естн зкземплирнБге методБг GetType, De- 
finedTypes и ExportedTypes. 

ПРИМЕЧАНИЕ 

Microsoft исполБзует нотацинз Бакуса-Наура длл записи имен типов и имен с указа- 
нием сборки, KOTopbie исполБзукзтсл длл написанил строк, передаваемБ1х в методБ! 
отраженил. Знание нотации оказнваетсл оченБ кстати при исполБЗОвании отраженил 
и особенно при работе с вложенннми типами, обобиденннми типами и методами, 
ссмлочнмми параметрами или массивами. За полнмм описанием нотации обра 1 даи- 
тесБ к документации FCL или вмполните поиск в Интернете по строке «Backus-Naur 
Form GrammarforType Names». Вм также можете посмотрењ методм МакеАггауТуре, 
MakeByRefType, MakeGenericType и MakePointerType классов Туре и Typelnfo. 

Во многих нзБгках программированин еств оператор, позволпгогции получитв 
oO'bCKT Туре по именгг типа. Длл полученгш ссбглки на Туре лучше исполБЗОватБ 
именно такои оператор, а не перечисленнБге методБг, так как пргг компилчцгш 
оператора получаетси более бБгстрБш код. В C# зто оператор typeof , хотн обкгчно 
его не применнгот дли сравнении информацгш о типах, загруженнвгх посредством 
позднего и раннего свнзвгвангш, как в следугогцем примере: 
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private static void SomeMethod(Object o) { 

// GetType возврашает тип обвекта во времв внполненив 
// (позднее свлзмвание) 

// typeof возврашает тип указанного класса 
// (раннее свлзмвание) 

if (o.GetType() == typeof(Filelnfo) ) { } 

if (o.GetType() == typeof(DirectoryInfo)) { ... } 

} 


ПРИМЕЧАНИЕ 

Первал инструкцил if провернет, сситаетсл ли переменнал о на обвекттипа Filelnfo, 
но не на тип, производнв 1 и от Filelnfo. Иначе говорп, зтот код проверлет на точное, 
а не на совместимое соответствие. Совместимое соответствие оби 1 чно достигаетсл 
путем приведенип типов либо исполвзованип оператора is или as пзмка С#. 


Как vno.viiina.TOCi) ранее, обЂект Туре представлнет ссмлку на тип, то естБ со- 
держит минимум информации. Дли полученин более полнои информации о типе 
следует получитБ обЂект TypeInfo, представликшдии определение типа. Обвект 
Туре можно преобразоватв в TypeInfo вб 130 вом метода расширенич GetTypeInfo 
класса System . Reflection . IntnospectionExtensions: 

Туре typeReference = ...; // Например: o.GetType() или typeof(Object) 

TypeInfo typeDefinition = typeReference.GetTypeInfo(); 

И хотл зта возможностб менее полезна, обљект TypeInfo можно преобразоватБ 
в обвект Туре вбгзовом метода AsType класса TypeInfo. 

TypeInfo typeDefinition = ...; 

Туре typeReference = typeDefinition . AsType( ); 

При получении обвекта TypeInfo CLR приходитсн убеждатвси в том, что сбор- 
ка, определмкииаи тип, загружена. Зто затратнан операцин, без которои можно 
обоитисБ, если вам достаточно ссбшок на типбг (обЂектБг Туре). Однако после полу- 
ченгш обнекта TypeInfo можно запрашиватБ многие своиства типа и узнатв о них 
много полезного. Болбшинство своиств, такихкак IsPublic, IsSealed, IsAbstnact, 
IsClass, IsValueType и т. д., описБшагот флаги, свчзаншле с типом. Другие свои- 
ства (к ним относитси Assembly, AssemblyQualifiedName, FullName, Module и пр.) 
возврагцагот ими сборки, в которои определен тип или модулв, и полное ими типа. 
При помогци своиства BaseType можно узнатв базовБпг тип. Все методБ 1 и своиства, 
предоставлиемБге типом TypeInfo, описанБ 1 в документации FCL. 

Создание иерархии типов, производннх от Exception 

В приложении-примере ExceptionTnee (исходнбш текст см. далее) описаннвш 
концепции исполБзуготси, что6б1 загрузитБ в домен приложении определенное 
подмножество сборок и показатв все типбг, которкк' в конечном итоге наследугот от 
типа System . Exception. Кстати, зто программа, которуго н написал, что6б1 создатБ 
иерархиго исклгочении, приведеннуго в главе 20. 
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public static void Go() { 

// Нвнал загрузка сборок длв отраженил 
LoadAssemblies(); 

// Филнтрацив и сортировка всех типов 
var allTypes = 

(from а in AppDomain.CurrentDomain.GetAssemblies() 
from t in a.ExportedTypes 

where typeof(Exception).GetTypeInfo().IsAssignableFrom(t.GetTypeInfo()) 
orderby t.Name 
select t).ToArray(); 

// Построение и вмвод иерархического дерева наследованип 
Console.WriteLine(WalkInheritanceHierarchy(new StringBuilder( ) , 0, 
typeof(Exception), 

allTypes)); 


private static StringBuilder WalkInheritanceHierarchy( 

StringBuilder sb, Int32 indent, Туре baseType, IEnumerable<Type> allTypes) { 
String spaces = new StringO ', indent * 3); 
sb.AppendLine(spaces + baseType.FullName); 
foreach (var t in allTypes) { 

if (t.GetTypeInfo().BaseType != baseType) continue; 
WalkInheritanceHierarchy(sb, indent + 1, t, allTypes); 


} 

return sb; 


private static void LoadAssemblies() { 

Stringf] assemblies = { 

"System, Publ 

"System.Core, Publ 

"System.Data, Publ 

"System.Design, Publ 

"System.DirectoryServices, Publ 
"System.Drawing, Publ 

"System.Drawing.Design, Publ 

"System.Management, Publ 

"System.Messaging, Publ 

"System.Runtime.Remoting, Publ 

"System.Security, Publ 

"System.ServiceProcess, Publ 

"System.Web, Publ 

"System.Web.RegularExpressions, 
"System.Web.Services, Publ 

"System.Xml, Publ 

}; 


icKeyToken={0}", 
icKeyToken={0}", 
icKeyToken={0}", 
icKeyToken={l}", 
icKeyToken={l}", 
icKeyToken={l}", 
icKeyToken={l}", 
icKeyToken={l}", 
icKeyToken={l}", 
icKeyToken={0}", 
icKeyToken={l}", 
icKeyToken={l}", 
icKeyToken={l}", 
PublicKeyToken={l}", 
icKeyToken={l}", 
icKeyToken={0}", 


String EcmaPublicKeyToken = "b77a5c561934e089"; 
String MSPublicKeyToken = "b03f5f7flld50a3a"; 


// Получение версии сборки, содержашеи System.Object. 


продолжение & 
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// Зтот же номер версии предполагаетсл длл всех осталвнух сборок. 

Version version = typeof(System.Object).Assembly.GetName().Version; 

// Нвнал загрузка сборок 
foreach (String a in assemblies) { 

String Assemblyldentity = 

String.Format(aj EcmaPublicKeyToken, MSPublicKeyToken) + 

", Culture=neutral, Version=" + version; 

Assembly.Load(AssemblyIdentity); 

} 

} 

Создание зкземпллра типа 

Получив ссмлку на обвект, производнми от Туре, можно создатБ зкземплир зтого 

типа. FCL предлагает дли зтого несколБКО механизмов. 

□ Методм Createlnstance класса System.Activator. Зтот класс поддерживает 
несколБКО перегруженнмх версии статического метода Createlnstance. При 
вмзове зтому методу передаетсн ссмлка на обвект Туре либо значение Stning, 
идентифициругогцее тип обвекта, которми нужно создатБ. Версии, принимак)- 
гцие тип Туре, прогце: вбг передаете методу набор аргументов конструктора, а он 
возврагцает ссбшку на новбш обвект. 

Версии Createlnstance, в которБ 1 Х желаемБП! тип задагот строкои, чутБ 
сложнее. Во-первБгх, дли них нужна егце и строка, идентифициругогцаи сборку, 
в которои определен тип. Во-вторБгх, зти методБ 1 позволигот создаватБ уда- 
леннБ1е обвектБц если правилБно настроитБ параметрБ1 удаленного доступа. 
В-третБих, вместо ссб 1 лки на новбш обвект зти версии метода возврагцагот 
обвект System . Runtime . Remoting.ObjectHandle (производнБ 1 и от System. 
MarshalByRefObject). 

ObjectHandle — зто тип, позволигогции передатБ обвект, созданнБп! в одном 
домене приложении, в другои домен, не загружаи в целевои домен приложении 
сборку, в которои определен зтот тип. Подготовившисб к работе с переданнБш 
обвектом, нужно вБИватБ метод Unwrap обвекта ObjectHandle. Толбко после зтого 
загружаетсл сборка, в которои находлтсл метаданнБ 1 е переданного типа. Если 
вБшолниетсл продвижение обвекта по ссБ1лке, создаготсл тип-представителБ 
и обБект-представителБ. При продвижении по значениго копин десериализуетси. 

□ Методм CreatelnstanceFrom обЂекта System.Activator. Класс Activator также 
поддерживает несколБКО статических методов CreatelnstanceFrom. Они не от- 
личаготсн от Createlnstance за исклгочением того, что длн них всегда нужно за- 
даватБ строковБши параметрами тип и сборку, в которои он находитсн. Заданнан 
сборка загружаетсл в вБ13Б1вагогции домен приложении методом Load F rom (а не 
Load) обвекта Assembly. Посколику ни один из методов CreatelnstanceFrom 
не принимает параметр Туре, все они возврагцагот ссишку на тип Ob jectHandle, 
KOTopbiii необходимо дополнителБно развернутБ. 
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□ Методм обЂекта System.AppDomain. Тип AppDomain поддерживает четмре 
зкземплирнмх метода (у каждого естћ несколЂКО перегруженнмх версии), соз- 
даклцих зкземплир типа: Createlnstance, CneateInstanceAndUnwrap, Create- 
IntanceFrom и CreateInstanceFromAndUnwrap. Они работагот совсем как методм 
Activator, но ИВЛИ 10 ТСН зкземплнрнБ 1 ми методами, позволни задатБ домен 
приложении, в котором нужно создатв обвект. МетодБ 1 , названии которБ 1 х 
оканчиваготси на Unwrap, удобнее, так как они позволнкзт обоитисв без допол- 
нителБного вБ130ва метода. 

□ Зкземплпрнми метод Invoke обЂекта System.Reflection.ConstructorInfo. 

При помогци ССБ 1 ЛКИ на обвект TypeInfo можно привнзатБСи к некоторому 
конструктору и получитБ ссБшку на обвект Constructorlnfo, что6б1 затем вбн 
зватБ его метод Invoke. Новбш обвект всегда создаетсл в вБИБшагогцем домене 
приложении, а затем возврагцаетсн ссвшка на новбпт обвект. К зтому методу mki 
тоже вернемсн позднее в зтои главе. 

ПРИМЕЧАНИЕ 

Среда CLR не требует, чтобм у значимого типа бнл конструктор. И зто создает про- 
блемБ1, таккак все перечисленнБ1е механизмБ! создакзт обвектпутем вБ130ваего кон- 
структора. Однако версии метода Createlnstance типа Activator позволлкзт создаватБ 
зкземпллрБ! значимБ 1 х типов без вшова их конструкторов. Чтобм создатБ зкземпллр 
значимого типа, не вмзБ 1 вал его конструктор, нужно вмзватБ версикз Createlnstance, 
принимаклцукз единственнни параметр Туре, или версикз, принимакзтукз параметрм 
Туре и Boolean. 

Зти механизмБг позволигот создаватв обЂектБг лго6бгх типов, кроме массивов 
(то еств типов, производшлх от System . Аггау) и делегатов (потомков типа System. 
MulticastDelegate). 4 to 6 bi создатБ массив, надо вБгзватБ статическии метод 
Createlnstance обвекта Аггау (сугцествует несколвко перегруженнкгх версии зтого 
метода). В первом параметре всех версии Createlnstance передаетсн ссвшкана о6ђ- 
ект Туре, описБшагогции тип злементов массива. Прочие параметрп Createlnstance 
позволнгот задаватв размерностБ и границБг массива. Длл созданин делегата следу- 
ет ББгзватБ статическии метод CreateDelegate обвекта Delegate (у зтого метода 
также естБ несколБКО перегруженнБгх версии). ПервБги параметр лгобои версии 
CreateDelegate — зто ссвшка на обвект Туре, описБшагогции тип делегата. ОсталБНБге 
параметрБг позволигот указатв, длл какого зкземплирного метода обвекта или длл 
какого статического метода типа делегат должен служитк оболочкои. 

Длн созданин зкземплнра обобгценного типа сначала нужно получитн ссБглку на 
открБгтБш тип, а затем впгзватБ открБгтБш зкземплирнБш метод MakeGenericType 
обвекта Туре, передав массив типов, которвги нужно исполвзоватБ в качестве пара- 
метров типа. Затем надо получитв возврагценнБги обвект Туре и передатк его в один 
из описаннБгх ранее методов. Вот пример: 

using System; 

using System.Reflection; 
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internal sealed class Dictionary<TKey, TValue> { } 

public static class Program { 
public static void Main() { 

// Получаем ссшжу на обБект Туре обобценного типа 
Туре орепТуре = typeof(Dictionary<, >); 

// Закриваем обобшеннии тип, исполБзул TKey=Stringj TValue=Int32 
Туре closedType = openType.MakeGenericType( 
new Type[] { typeof(String)j typeof(Int32) }); 

// Создаем зкземпллр закрмтого типа 

Object о = Activator.CreateInstance(closedType); 

// Проверлем, работает ли наше решение 
Console.WriteLine(o.GetType()); 

} 

} 


Скомпилировав и вмполнив зтот код, мм получим: 

Dictionary' 2 [System . String,System.Int32] 


Создание приложении c поддержкои 
подклк)чаемБ1х компонентов 

В построении открмтмх расширнеммх приложении централвное место занимагот 
интерфеисм. Вместо них можно бмло бм задеиствоватБ базовме классм, но в обндем 
случае интерфеис предпочтителБнее, так как позволиет разработчику подклгочаемо- 
го компонента (add-in) вБгбратБ собственнБге базовБге классБт Допустим, вбг хотите 
создатБ приложение, позволнгогцее полвзователим создаватв типбг, KOTopbie ваше 
приложение сможет загружатв и применитв. Такое приложение должно строитксн 
следугошим образом. 

□ Создаите сборку длн хоста, определнклцуго интерфеис с методами, обеспечиваго- 
гцими взаимодеиствие вашего приложенгш с подклгочаемвши компонентами. 
Определлл параметрБ 1 и возврагцаемБге значенгш методов зтого интерфеиса, 
постараитесв задеиствоватБ другие интерфеисБг или типбг, определеннвге 
BMSCorLib.dll. Если нужно передаватв и возврагцатБ собственнБге типбг дашшх, 
определите их в зтои же сборке. Задав интерфеис, даите сборке строгое имн 
(см. главу 3), после чего можете передатв ее своим партнерам и полвзователим. 
После публикацгш нужно избегатв лго6бгх измененгш типов сборки, которвге 
могут нарушитБ работу подклгочаемБгх модулеи. В частности, вообгце нелвзн 
изменнтБ интерфеис. Но если вбг определили типбг ддннбгх, ничего не случитси, 
если вб1 добавите в них новвге членБг. Внесл какие-либо измененгш в сборку, 
нужно развертвшатБ ее вместе с фаилом политики издателн (см. главу 3). 
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ПРИМЕЧАНИЕ 

Bbi можете исполнзоватитипм, определенние в MSCorLib.dll: CLR всегда загружает 
ту версинз MSCorLib.dll, которал соответствует версии самои средн CLR. Кроме того, 
в процесс всегдазагружаетсл толико одна версил MSCorLib.dll. Иначе говорл, разнме 
версии MSCorLib.dll никогда не загружакзтсл совместно (см. главу 3). В итоге несо- 
ответствии версии типа не будет, и ваше приложение исполвзует менише памити. 


□ Разработчики подклгочаеммх компонентов, конечно, определлт свои типв1 
в собственнмх сборках. Кроме того, их сборки будут ссмлатБСи на вашу интер- 
феиснукз сборку. Сторонние разработчики также смогут вћгдаватБ новбш версии 
своих сборок, когда захотлт: приложение сможет восприниматБ подклгочаемБге 
типб1 без проблем. 

□ Создаите сборку, содержагцуго типбг вашего приложении. Очевидно, она будет 
ссБшатБСи на интерфеис и типбг, определеннБге в первои сборке. Код сборки вбг 
можете изменнтБ как угодно. Посколкку разработчики подклгочаемкгх компо- 
нентов не ссвшаготси на зту сборку, вбг можете в лгобои момент ввгдатБ ее новуго 
версиго, и зто не затронет сторонних разработчиков. 

Зтот короткии раздел содержит оченв важнуго информациго. Исполвзуи типбг 
в разнвгх сборках, нелкзи забБшатБ о версинх. Не пожалеите времени и ввгделите 
в отделБнуго сборку типбг, которБге вбг применнете длн взаимодеиствин между сбор- 
ками. Избегаите изменении зтих типов и номера версии такои сборки. Однако если 
вам деиствителБно нужно изменитБ определенин типов, обнзателвно поменните 
номер версии и создаите фаил политики издателл длл новои версии. 

А теперв мбг рассмотрим один оченн простои сценарии, в котором исполвзуетсн 
все, о чем мбг говорили. Во-перввгх, нам нужен код сборки длл хоста: 

using System; 

namespace Wintellect.HostSDK { 
public interface IAddln { 

String DoSomething(Int32 х); 

} 

} 

Затем идет код сборки подклгочаемого компонента — библиотеки AddlnTypes.dll, 
в которои определенвг два открвгтвгх типа, реализугогцие интерфеис HostSDK. Длн 
построенгш SToii сборки необходимо добавитн ссбшку на HostSDK.dll: 

using System; 

using Wintellect.HostSDK; 

public sealed class AddIn_A : IAddln { 
public AddIn_A() { 

} 

public String DoSomething(Int32 х) { 
return "AddIn_A: " + x.ToString(); 
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} 

} 

public sealed class AddIn_B : IAddln { 
public AddIn_B() { 

} 

public String DoSomething(Int32 х) { 

netunn "AddIn_B: " + (х * 2).ToStning(); 

} 

} 

ТретБим рассмотрим код сборки простого хоста (консолбного приложенин) — 
фаила Host.exe. При построении зтои сборки исполБзуетсн ссћшка на HostSDK.dll. 
Определнн исполБзуемБге подклгочаемБш модулем типб1, код хоста предполагает, что 
искомкге ТИПБ1 определенБ1 в сборках, фаилБ1 которБ1х содержат расширение dll, а сами 
сборки развернутБг в том же каталоге, что и ЕХЕ-фаил хоста. Библиотека Microsoft 
MEF (Managed Extensibility Framework) строитсл на базе различнБ 1 х механизмов, 
которвге и демонстрируго в зтом разделе, а также предоставллет дополнителБнвге 
средства регистрации и поиска подклгочаемвгх компонентов. Если bbi занимаетесв 
построением динамически расширнемБ1х приложении, н рекомендуго поближе по- 
знакомитБСи с MEF, потому что зто упростит частн материала зтои главБг 

using System; 

using System.IO; 

using System.Reflection; 

using System.Collections.Genenic; 

using Wintellect.HostSDK; 

public static class Program { 
public static void Main() { 

// Находим каталог, содержатии фаил Host.exe 
Stning AddlnDir = 

Path.GetDirectoryName(Assembly.GetEntryAssembly().Location); 

// Предполагаетсл, что сборки подклгачаемћ 1 х модулеи 

// находлтсл в одном каталоге с ЕХЕ-фаилом хоста 

var AddlnAssemblies = Directory . EnumerateFiles(AddInDir, "*.dll"); 

// Создание набора обБектов Туре, которме могут 
// исполБЗОвате.сл хостом 
var AddInTypes = 

from file in AddlnAssemblies 
let assembly = Assembly.Load(file) 

from t in assembly.ExportedTypes // Открнто зкспортируемме типт 
// Тип может исполвзоватвсл, если зто класс, реализуадии IAddln 
where t.IsClass && 

typeof(IAddln).GetTypeInfo().IsAssignableFrom(t.GetTypeInfo()) 

select t; 

// Инициализацил завершена: хост обнаружил типш, пригоднме длл исполцзованил 
// Пример конструированил обвектов подклтчаемшх компонентов 
// и их исполцзованил хостом 
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foreach (Туре t in AddInTypes) { 

IAddln ai = (IAddln) Activator.Createlnstance(t); 

Console.WriteLine(ai.DoSomething(S)); 

} 

} 

} 

B зтом простом примере не исполћзукзтсн доменм приложении. Однако в реалБ- 
нои жизни подклгочаемме модули создаготсн в собственнмх доменах приложении 
с собственнмми параметрами затцитн и конфигурированин. И, конечно же, домен 
приложении можно вмгрузитБ, если нужно удалитБ подклгочаемБш модулБ из 
памнти. Что 6 б 1 обеспечитБ взаимодеиствие между доменами приложении, лучше 
всего потребоватв от разработчиков подклгочаемБ1х модулеи создаватБ собствен- 
HBie внутренние типбр производнБге от MarshalByRefObject. При создании нового 
домена приложении хост создаст в нем зкземплнр собственного производного от 
MarshalByRefObject типа. Код хоста (в основном домене) будет взаимодеиство- 
ватв с собственнБш типом (в других доменах), заставлии их загружатв сборки 
подклгочаемБ1х модулеи, создаван и исполвзул зкземплнрБ1 определеннБ1х в зтих 
модуллх типов. 


Нахождение членов типа путем отраженич 

До настонгцего момента н рассказвшал о тех составлнгогцих механизма отраженин — 
загрузке сборок, нахождении типов и создании обвектов, — которвге необходимвг 
длл созданин динамически расширнемБгх приложении. Однако, чтобкг обеспечитБ 
вБгсокуго производителБностБ и безопасностБ типов во времн компилнции, нужно 
избегатв отраженин. В динамически расшириемом приложении после созданин 
обЂекта код хоста обкгчно приводит обвект к интерфеисному типу (зто предпо- 
чтителБНБш вариант) или базовому классу, известному на момент компилнции; зто 
обеспечивает бвгстроту доступа к членам обвекта и безопасноств типов во времл 
компилиции. 

В оставшеиси части зтои главвг н рассказБгваго о некоторвгх аспектах отраженин, 
применнемБгх длл нахожденин и внгзова членов типа. Возможностб поиска и вбг- 
зова членов типа обвгчно нужна при создании инструментов длл разработчиков 
и средств анализа сборок, ориентированнвгх на вБшвление определеннвгх структур 
в программном коде или исполБЗОвание определеннвгхчленов. В качестве примера 
таких инструментов приведу ILDasm, FxCop и конструкторвг форм длн приложении 
Windows Forms и Web Forms, разрабатвгваемБгх в Visual Studio. Также в некоторвгх 
библиотеках классов сугцествует возможностб нахожденин и вБгзова членов типа 
дли предоставленгш разработчикам расширеннои функционалБности. Пример — 
библиотеки, обеспечивагогцие сериализациго и десериализациго, а также простуго 
привнзку к даннБгм. 
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Нахождение членов типа 

Членами типа могут 6мтб поли, конструкторм, методм, своиства, собмтин и вло- 
женнме типм. В FCL естБ тип System. Reflection .Memberlnfo — абстрактнБш 
класс, инкапсулиругогции набор своиств, обгцих длн всехчленов типа. У Memberlnfo 
много дочерних классов, каждБШ из которБгх инкапсулирует чутк болБше своиств 
отделвнБгх членов типа (рис. 23.1). 



Рис. 23.1. Иерархич типов отраженич 


Приведеннаи далее программа демонстрирует, как нужно запрашиватв членБ1 
типа и вбшодитб информацшо о них. Зтот код обрабаткшает все открвгтвге типбг всех 
сборок, загруженнвгх в вБгзвшакнции домен приложении. Длл каждого типа вбгзбг- 
ваетсн своиство DeclaredMembers, которое возврагцает коллекциго обвектов тггпа, 
производного от Memberlnf о; каждвги обвект опггсБгвает один член ггз определеннвгх 
в тггпе. Далее длн каждого члена вбгводлтсн его описангге (поле, конструктор, метод, 
своиство и т. п.) гг строковое значение (полученное вбгзовом ToString). 

using System; 

using System.Reflection; 


public static class Program { 
public static void Main() { 

// Перебор всех сборок, загруженннх в домене 

Assembly[] assemblies = AppDomain.CurrentDomain.GetAssemblies(); 
foreach (Assembly a in assemblies) { 
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Show(0, "Assembly: {0}", а); 

// Поиск типов в сборке 

foreach (Туре t in а. ExportedTypes) { 

Show(lj "Туре: {0}", t); 

// Получение информации о членах типа 

foreach (Memberlnfo mi in t.GetTypeInfo().DeclaredMembers) { 

String typeName = String.Empty; 

if (mi is Туре) typeName = "(Nested) Туре"; 

if (mi is Fieldlnfo) typeName = "Fieldlnfo"; 

if (mi is Methodlnfo) typeName = "Methodlnfo"; 

if (mi is Constructorlnfo) typeName = "Constructolnfo"; 

if (mi is PropertyInfo) typeName = "PropertyInfo"; 

if (mi is Eventlnfo) typeName = "Eventlnfo"; 

Show(2, "{0}: {1 }"j typeNamej mi); 

} 

} } 

} 

private static void Show(Int32 indent, String format, params Object[] args) { 
Console.WriteLine(new String(' ', 3 * indent) + format, args); 

} 

} 

После компилиции и запуска приложенин мм получаем массу информации. 
Вот ее частБ: 

Assembly: mscorlib, Version=4. 0.0.0, Culture=neutral, 

PublicKeyToken=b77a5c561934e089 
Туре: System.Object 

Methodlnfo: System.String ToString() 

Methodlnfo: Boolean Equals(System.Object) 

Methodlnfo: Boolean Equals(System.Object, System.Object) 

Methodlnfo: Boolean ReferenceEquals(System.Object, System.Object) 

Methodlnfo: Int32 GetHashCode() 

Methodlnfo: System.Type GetType() 

Methodlnfo: Void Finalize() 

Methodlnfo: System.Object MemberwiseClone() 

Methodlnfo: Void FieldSetter(System.String, System.String, System.Object) 
Methodlnfo: Void FieldGetter(System.String, System.String, 

System.Object ByRef) 

Methodlnfo: System.Reflection.Fieldlnfo GetFieldInfo(System.String, 
System.String) 

Constructolnfo: Void .ctor() 

Туре : System.Collections.Generic.IComparer'1[T] 

Methodlnfo: Int32 Compare(T, T) 

Туре : System.Collections.IEnumerator 
Methodlnfo: Boolean MoveNext() 

Methodlnfo: System.Object get_Current() 

Methodlnfo: Void Reset() 

PropertyInfo: System.Object Current 
Туре: System.IDisposable 
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Methodlnfo: Void Dispose() 

Туре: System.Collections.Generic.IEnumerator'1[T] 

Methodlnfo: T get_Current() 

PropertyInfo: T Current 
Туре: System.ArraySegment'1[T] 

Methodlnfo: T[] get_Array() 

Methodlnfo: Int32 get_Offset() 

Methodlnfo: Int32 get_Count() 

Methodlnfo: Int32 GetHashCode() 

Methodlnfo: Boolean Equals(System.Object) 

Methodlnfo: Boolean Equals(System.ArraySegment'1[T]) 

Methodlnfo: Boolean op_Equality(System.ArraySegment'1[T], 

System.ArraySegment'1[T]) 

Methodlnfo: Boolean op_Inequality(System.ArraySegment'1[T], 

System.ArraySegment'1[T]) 

Constructolnfo: Void .ctor(T[]) 

Constructolnfo: Void .ctor(T[], Int32, Int32) 

PropertyInfo: T[] Аггау 
PropertyInfo: Int32 Offset 
PropertyInfo: Int32 Count 
Fieldlnfo: T[] _array 
Fieldlnfo: Int32 _offset 

Так как тип Memberlnf o нвлиетсл корнем иерархии, стоит обсудитБ его подроб- 
нее. В табл. 23.1 показанБ 1 некоторБге неизменнемБге (толбко длн чтенин) своиства 
и методБ 1 типа Memberlnf о, обгцие длл всех членов типа. Как bbi помните, System . 
Туре наследует от типа Memberlnfo, позтому Туре также обладает всеми перечис- 
леннвши в таблице своиствами. 


Таблица 23.1. Своиства и методБ 1 , обидие дла всехтипов, производнБ 1 х 
от Memberlnfo 


Имл члена 

Тип члена 

Описание 

Name 

Своиство String 

Возврагцает имл члена 

DeclaringType 

Своиство Туре 

Возврагцает тип, обвлвллгогции член 

Module 

Своиство Module 

Возврагцает модулв, обвлвллгохции член 

С ustom Attributes 

Своиство, возвра- 
гцакицее IEnumer 
able< Custom Attri 
buteData> 

Возврагцает коллекциго, каждвш злемент кото- 
рои идентифицирует зкземпллр настраиваемо- 
го атрибута, которим помечен зтот член. Такие 
атрибутв! могут применнтвсл к лгобому члену. 

И хотн тип Assembly не наследует от Member- 
Info, он предоставллет такое же своиство, ко- 
торое может исполБзоватБсл со сборками 


Каждвш злемент коллекции, возврагцаемои DeclaredMembers, представлнет собои 
ссБшку наконкретнБш тип из зтои иерархии. Помимо метода DeclaredMembers, воз- 
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Bpainaiomem все членм типа, TypeInfo также поддерживает методм, возврашаговдие 
определеннме разновидностичленов: GetDeclaredNestedType, GetDeclaredField, 
GetDeclaredMethod, GetDeclaredProperty и GetDeclaredEvent. Bce зти методм 
возврашамт ссмлку на обнект TypeInfo, Fieldlnfo, Methodlnfo, PropertyInfo или 
Eventlnfo соответственно. Также сушествует метод GetDeclaredMethods, возвра- 
шаговдии коллекциго обнектов Methodlnf о с описанием методов, соответствуготцих 
заданному строковому имени. 

На рис. 23.2 представлена сводка типов, исполБзуеммх приложенинми длл обхода 
модели обнектов отраженин. Домен приложении (AppDomain) дает возможностб 
узнатБ, какие сборки в него загруженм, сборка (Assembly) — из каких модулеи она 
состоит, а сборка (Assembly) или модулБ (Module) — определнемме в них типм. 
В свого очередБ, тип (Туре) позволиет получитБ информациго обо всех его членах 
(вложеннме типм, по./ш, конструкторм, методм, своиства и собмтин). Пространства 
имен не входит в иерархиго, так как они представлнгот собои синтаксические наборм 
типов. Если нужно перечислитБ все пространства имен, определеннБ1е в сборке, 
достаточно перечислитБ все типб! в сборке и просмотретв их своиства Namespace. 



Рис. 23.2. Tnnbi, исполБзуемне приложенилми дла обхода обнектнои модели отраженил 

Тип позволиет также находитв реализуемБ1е им интерфеисБ1 (как зто сделатк, 
а покажу позже). И из конструктора, метода, метода-аксессора своиства или метода 
создашш/удаленин сообгценгш можно ввговатБ метод GetParameters, что 6 б 1 полу- 
читб массив обнектов Parameterlnfo, которвге информиругот вас о типах параметров 
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членов. Можно также запроситБ своиство ReturnParameten, что6бг получитБ обвект 
Parameterlnf о с подробнои информациеи о возврандаемом значении члена. Чтобвг 
получитв набор параметров типа длн обобнденнвгх типов и методов, можно вбгзбг- 
ватБ метод GetGenericArguments. Наконец, что6бг получитБ набор нестандартннгх 
атрибутов, примененнБгх ко всем указаннвш сундностлм, можно вБгзншатБ метод 
GetCustomAttributes. 


Обраицение к членам типов 

Итак, вб 1 знаете, как получитн информациго о членах типа. Следуготцим шагом 
должно статБ обрагцение к одному из зтих членов. Термин <<обрагцение>> в данном 
случае зависит от разновидности члена. В табл. 23.2 указано, какие методвг следует 
ББгзБшатБ в каждом конкретном случае. 


Таблица 23.2. МетодБ! обраиденич к членам типов 


Тип 

Описание 

Fieldlnfo 

Метод GetValue получает значение полл, метод SetValue — задает 
его значение 

Constructorlnfo 

Метод Invoke создает зкземплнр типа и вмзнвает конструктор 

Methodlnfo 

Метод Invoke внзнвает метод типа 

PropertyInfo 

Метод GetValue ввгзвгвает метод доступа get, метод SetValue — 
метод доступа set длл своиства 

Eventlnfo 

Метод AddEventHandler вћгзнвает метод add, метод 
RemoveEventHandler — метод remove длл собвгош 


Тип PropertyInfo представллет информациго метаданнБ 1 х своиств (см. гла- 
ву 10 ), поддерживаи доступнБ 1 е толбко длл чтенгш своиства CanRead, CanWrite 
и PropertyType. Зти своиства показвшагот, можно ли читатн и записБшатБ своиство, 
а также его тип даннвгх. У PropertyInf о также естк своиства GetMethod и SetMethod, 
возврагцагогцие о6бсктб1 Methodlnfo длн методов чтенгш и записи значенгш свои- 
ства. Методвг GetValue и SetValue типа PropertyInfo сугцествугот дли удобства, 
их внутреннии код получает соответствугогцие обвектБг Methodlnfo и вБгзБгвает 
их. Дли поддержкгг параметрическггх своиств (индексаторов С#) методвг SetValue 
и GetValue предоставлигот параметр index тггпа Object [ ]. 

Тггп Eventlnfo представлиет метаггнформациго собвгтии (см. главу 11). Он 
поддерживает доступное толбко длл чтенггн своиство EventHandlerType, которое 
возврагцает обвект Туре длл делегата собвгтил. У Eventlnfo также еств своиства 
AddMethod и RemoveMethod, которвге возврагцагот обвектвг Methodlnf о длл методов 
добавленин и удаленгш делегатов. Чтобвг добавитв гглгг удалитБ делегата, можно 
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обратитБСн с вБ130вом к зтим обвектам Methodlnfo или же восполБЗОватћсл более 
удобнБши методами AddEventHandlen и RemoveEventHandlen класса Eventlnfo. 

В приведенном далее приложении-примере демонстрируготсн разнвге спосо 6 б 1 
применении отражении длн доступа к членам типа. Класс SomeType представлиет 
тип с различнБши членами: закрБ1ТБш полем (m_someField), открБ1ТБ1м конструк- 
тором (SomeType), получакпцим аргумент типа Int32 по сскшке, открбпбш методом 
(ToStning), открБггБш CBOiicTBOM (SomePnop) и открБПБш собБпием (SomeEvent). 
При наличии определении типа SomeType л также могу предложитк три разнБ 1 х 
метода исполБЗОвангш отраженгш длл доступа к членам SomeType. Каждвги метод 
задеиствует отражение по-своему. 

□ Метод BindToMembenThenlnvokeTheMemben демонстрирует привнзку и после- 

ДУКНЦИИ ВБ130В. 

□ Метод BindToMembenCneateDelegateToMembenThenlnvokeTheMemben демонстри- 
рует привизку с последуклцим созданием делегата, ссвшаклцетосн на обвект или 
член. Bbi30b через делегата ввшолнлетсл оченв бБ 1 Стро, и зтот вариант позволнет 
егце болвше повб1Ситб производителБностБ программного кода длл случаев 
многократного ввиова одинаковБгх членов разнвши обвектами. 

□ Метод UseDynamicToBindAndInvokeTheMemben демонстрирует исполБЗОвание 
в изБ 1 ке C# примитивного типа dynamic (см. главу 5) с це.њк) упрогценгш син- 
таксиса доступа к членам. К тому же зтот вариант может помочб до 6 итбсн деи- 
ствителБно хорошеи производителБности программного кода длл случаев ввшова 
одинаковБ1х членов разнвши обвектами, потому что свнзкшание происходит один 
раз длл каждого типа и затем кзшируетсл таким образом, что 6 б 1 последуклции 
многократнБ1и вб130в членов происходил бвгстро. Bbi также можете исполБЗОватБ 
зтот вариант с целвк) вБИОва членов длл обвектов различнвш типов. 

using System; 

using System.Reflection; 

using Micnosoft.CSharp.RuntimeBinder; 

using System.Linq; 

// Класс длл демонстрации отраженил. 

// У него ecTb поле, конструктор, метод, своиство и собмтие 
intennal sealed class SomeType { 
private Int32 m_someField; 
public SomeType(nef Int32 х) { х *= 2; } 

public ovenride Stning ToString() { neturn m_someField.ToString(); } 
public Int32 SomeProp { 

get { return m_someField; } 
set { 

if (value < 1) 

throw new ArgumentOutOfRangeException("value"); 
m_someField = value; 

} 

public event EventHandler SomeEvent; 
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private void NoCompilerWarnings() { SomeEvent.ToStringO ;} 

} 

public static class Program { 
public static void Main() { 

Туре t = typeof(SomeType); 
BindToMemberThenlnvokeTheMember(t); 

Console.WriteLine(); 

BindToMemberCreateDelegateToMemberThenlnvokeTheMember(t); 
Console.WriteLine(); 

UseDynamicToBindAndInvokeTheMember(t); 

Console.WriteLine(); 


private static void BindToMemberThenInvokeTheMember(Type t) { 

Console.WriteLine("BindToMemberThenInvokeTheMember"); 

// Создание зкземпллра 

Туре ctorArgument = Type.GetType("System.Int32&"); 

// или typeof(Int32).MakeByRefType(); 

Constructorlnfo ctor = t.GetTypeInfo().DeclaredConstructors.First( 
c => c.GetParameters()[0].ParameterType == ctorArgument); 

Objectf] args = new Object[] { 12 }; // Аргумен™ конструктора 

Console.WriteLine("x before constructor called: " + args[0]); 

Object obj = ctor.Invoke(args); 

Console.WriteLine("Type: " + obj.GetType()); 

Console.WriteLine("x after constructor returns: " + args[0]); 

// Чтение и записи в поле 

Fieldlnfo fi = obj.GetType().GetTypeInfo().GetDeclaredField("m_someField"); 
fi.SetValue(obj, 33); 

Console.WriteLine("someField: " + fi.GetValue(obj)); 

// Bbi30B метода 

Methodlnfo mi = obj.GetType().GetTypeInfo().GetDeclaredMethod("ToString"); 
String s = (String)mi.Invoke(obj, null); 

Console.WriteLine("ToString: " + s); 

// Чтение и записи своиства 

PropertyInfo pi = obj.GetType().GetTypeInfo().GetDeclaredProperty("SomeProp"); 
try { 

pi.SetValue(obj, 0, null); 

} 

catch (TargetInvocationException e) { 

if (e.InnerException.GetType() != typeof(ArgumentOutOfRangeException)) throw; 
Console.WriteLine("Property set catch."); 

} 

pi.SetValue(obj, 2, null); 

Console.WriteLine("SomeProp: " + pi.GetValue(obj, null)); 
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// Добавление и удаление делегата длн собмтил 

Eventlnfo ei = obj.GetType().GetTypeInfo( ) .GetDeclaredEvent("SomeEvent" ); 
EventHandler eh = new EventHandler(EventCallback); // См. ei.EventHandlerType 
ei.AddEventHandler(obj, eh); 
ei.RemoveEventHandler(obj , eh); 


// Добавление метода обратного вмзова длн собмтин 

private static void EventCallback(Object sender, EventArgs e) { } 

private static void BindToMemberCreateDelegateToMemberThenInvokeTheMember(Type t) { 
Console.WriteLine("BindToMemberCreateDelegateToMemberThenInvokeTheMember"); 

// Создание зкземплнра (нелизл создати делегата длл конструктора) 

Object[] args = new Object[] { 12 }; // Аргументн конструктора 

Console.WriteLine("x before constructor called: " + args[0]); 

Object obj = Activator.CreateInstance(t, args); 

Console.WriteLine("Type: " + obj.GetType().ToString()); 

Console.WriteLine("x after constructor returns: " + args[0]); 

// ВНИМАНИЕ : нелизн создатБ делегата длн полл. 

// Bbi30B метода 

Methodlnfo mi = obj.GetType().GetTypeInfo().GetDeclaredMethod("ToString"); 
var toString = mi.CreateDelegate<Func<String>>(obj); 

String s = toString(); 

Console.WriteLine("ToString: " + s); 

// Чтение и записи своиства 

PropertyInfo pi = obj.GetType().GetTypeInfo().GetDeclaredProperty("SomeProp"); 
var setSomeProp = pi.SetMethod.CreateDelegate<Action<Int32>>(obj); 
try { 

setSomeProp(0); 

} 

catch (ArgumentOutOfRangeException) { 

Console.WriteLine("Property set catch."); 

} 

setSomeProp(2); 

var getSomeProp = pi.GetMethod.CreateDelegate<Func<Int32>>(obj); 
Console.WriteLine("SomeProp: " + getSomeProp()); 

// Добавление и удаление делегата длл собмтин 

Eventlnfo ei = obj.GetType().GetTypeInfo().GetDeclaredEvent("SomeEvent"); 
var addSomeEvent = ei.AddMethod.CreateDelegate<Action<EventHandler>>(obj); 
addSomeEvent(EventCallback); 
var removeSomeEvent = 

ei.RemoveMethod.CreateDelegate<Action<EventHandler>>(obj); 
removeSomeEvent(EventCallback); 


private static void UseDynamicToBindAndInvokeTheMember(Type t) { 
Console.WriteLine("UseDynamicToBindAndInvokeTheMember"); 
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// Создание зкземпллра (dynamic нелнзл исполнзоватн длл вмзова конструктора) 
Object[] args = new Object[] { 12 }; // Аргумен™ конструктора 

Console.WriteLine("x before constructor called: " + args[0]); 
dynamic obj = Activator.CreateInstance(tj args); 

Console.WriteLine("Type: " + obj.GetType().ToString()); 

Console.WriteLine("x after constructor returns: " + args[0]); 

// Чтение и записн полл 
try { 

obj,m_someField = 5; 

Int32 v = (Int32)obj.m_someField; 

Console.WriteLine("someField: " + v); 

} 

catch (RuntimeBinderException e) { 

// Получает управление, потому что поле лвллетсл приватнмм 
Console.WriteLine("Failed to access field: " + e.Message); 

} 

// Bbi30B метода 

String s = (String)obj.ToString(); 

Console.WriteLine("ToString: " + s); 

// Чтение и записи своиства 
try { 

obj.SomeProp = 0; 

} 

catch (ArgumentOutOfRangeException) { 

Console.WriteLine("Property set catch."); 

} 

obj.SomeProp = 2; 

Int32 val = (Int32)obj.SomeProp; 

Console.WriteLine("SomeProp: " + val); 

// Добавление и удаление делегата длл собмтил 
obj.SomeEvent += new EventHandler(EventCallback); 
obj.SomeEvent = new EventHandler(EventCallback); 

} 

} 

internal static class ReflectionExtensions { 

// Метод расширенивЈ упрошакхции синтаксис созданил делегата 

public static TDelegate CreateDelegate<TDelegate>(this Methodlnfo mi, 

Object target = null) { 

return (TDelegate)(Object)mi.CreateDelegate(typeof(TDelegate), target); 

} 

} 

Если построитБ и запуститБ зтот код, будет вБшеден следуклции резулптат; 

BindToMemberThenlnvokeTheMember 
х before constructor called: 12 
Туре: SomeType 

х after constructor returns: 24 
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someField: 33 
ToString: 33 
Property set catch. 

SomeProp: 2 

BindToMemberCreateDelegateToMemberThenlnvokeTheMember 
х before constructor called: 12 
Туре: SomeType 

х after constructor returns: 24 
ToString: 0 
Property set catch. 

SomeProp: 2 

UseDynamicToBindAndInvokeTheMember 
х before constructor called: 12 
Туре: SomeType 

х after constructor returns: 24 

Failed to access field: ’SomeType.m_someField’ is inaccessible due to 
its protection level 
ToString: 0 
Property set catch. 

SomeProp: 2 

Обратите внимание: в единственном параметре конструктора SomeType по ссмлке 
передаетсл Int32. В представленном коде показано, как вмзватБ зтот конструктор 
и как после завершенин конструктора проверитБ модифицированное значение Int32. 
Далее в начале метода BindToMemberThenlnvokeTheMember присутствует вбшов ме- 
тода GetType типа Туре, которому передаетсл строка "System . Int32&". Амперсанд 
(&) в строке обозначает параметр, передаваемБш по ссћшке. Зто предусмотрено 
нотациеи Бзкуса-Наура длн записи имен типов (подробнее о неи см. документацшо 
на FCL). В коде также показано, как добитБСн того же резулБтата с исполБЗОванием 
метода MakeByRefType класса Туре. 

Исполвзование дескрипторов приввзки 
длв сниженив потребленив памвти процессом 

Во многих приложенгшх требуетсл привнзка к несколвким типам (то естк обвектам 
Туре) или их членам (обвектам, производнБш от Memberlnfo), а зти обвектБ 1 со- 
храннготсл в определеннои коллекции. Позже приложение шцет нужнвш обвект в 
коллекции и ввгоБшает его. Зто разумное решение, но естн одна загвоздка: обвектБ 1 
Туре и о 6 ђсктр> 1 , производнБге от Memberlnf о, занимагот много места в памлти. По- 
зтому если в приложении много таких обвектов и к ним надо обрагцатвсл часто, 
обп>ем потребллемои памнти резко возрастает, что отрицателвно сказБгваетсл на 
производителБности. 

Внутренние механизмБг CLR поддерживагот более компактнуго форму храненгш 
зтои информации. CLR создает такие обБектБг в приложенгшх лишб длн того, что6бг 
упроститБ работу программиста. Самои среде CLR длн работнг зти болБшие обБектБг 
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не нужнм. В приложенинх, в котормх сохраннетсл и кзшируетсл много обвектов 
Туре и обЂектов-потомков Memberlnfo, можно сократитБ потребление памлти, если 
исполБЗОватБ не обвектм, а описатели времени вмполнешш. В FCL определенм 
три типа таких описателеи (все в пространстве имен System): RuntimeTypeHandle, 
RuntimeFieldHandle и RuntimeMethodHandle. Все они — значимме типм с единствен- 
нмм полем IntPtn; за счет чего расходугот оченБ мало ресурсов (то еств памлти). 
Поле IntPtr представлнет собои дескриптор, ссвшагогцииси на тип, поле или метод 
в куче загрузчика домена приложении. Так что теперв нам достаточно научитвсн 
просто и зффективно преобразоввшатБ «тлжелБ1е» обЂектБг Туре и Memberlnfo 
в «легкие» дескрипторБг времени ввшолненгш, и наоборот. Зто не сложно, если 
задеиствоватБ перечисленнБге далее методБг и своиства. 

□ Чтобвг преобразоватБ обЂект Туре в RuntimeTypeHandle, ввгзовите статическии 
метод GetTypeHandle обвекта Туре, передав ему ссвшку на обЂект Туре. 

□ Что6бг преобразоватв RuntimeTypeHandle в обвект Туре, ввгзовите статическии 
метод GetTypeFromHandle обвекта Туре, передав ему RuntimeTypeHandle. 

□ Чтобвг преобразоватБ обЂект Fieldlnfo в RuntimeFieldHandle, запросите зк- 
земплнрное неизменнемое своиство FieldHandle обвекта Fieldlnfo. 

□ Чтобвг преобразоватБ RuntimeTypeHandle в обвект Fieldlnfo, ввгзовите стати- 
ческии метод GetTypeFromHandle обвекта Fieldlnfo. 

□ Чтобвг преобразоватБ обЂект Methodlnfo в RuntimeMethodHandle, запросите 
зкземплнрное неизмениемое своиство MethodHandle обвекта Methodlnfo. 

□ Чтобвг преобразоватБ RuntimeTypeHandle в обвект Methodlnfo, ввгзовите ста- 
тическии метод GetMethodFromHandle обвекта Methodlnfo. 

В приведеннои далее программе создаетсл много обвектов Methodlnfo, которвге 
преобразуготсн в зкземплнрБг RuntimeMethodHandle, а затем вбшодитсн информацгш 
о разнице в обвеме потреблиемои памнти: 

using System; 

using System.Reflection; 

using System.Collections.Generic; 

public sealed class Program { 

private const BindingFlags c_bf = BindingFlags.FlattenHierarchy | 

BindingFlags.Instance | 

BindingFlags.Static | BindingFlags.Public | BindingFlags.NonPublic; 

public static void Main() { 

// Вмводим размер кучи до отраженид 
Show("Before doing anything"); 

// Создаем кзш обкектов Methodlnfo длл всех методов из MSCorlib.dll 

List<MethodBase> methodlnfos = new List<MethodBase>( ); 

foreach (Туре t in typeof(Object).Assembly.GetExportedTypes()) { 
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// Игнорируем обобшеннне типа 

if (t . IsGenericTypeDefinition) continuej 

MethodBase[] mb = t.GetMethods(c_bf); 
methodlnfos.AddRange(mb); 

} 

// Вмводим количество методов и размер кучи после привнзки всех методов 
Console.WriteLine("# of methods={0:N0}"j methodlnfos.Count); 

Show("After building cache of Methodlnfo objects"); 

// Создаем кзш дескрипторов RuntimeMethodHandles 
// длн всех обиектов Methodlnfo 
List<RuntimeMethodHandle> methodHandles = 
methodlnfos.ConvertAll<RuntimeMethodHandle>(mb => mb.MethodHandle); 

Show("Holding Methodlnfo and RuntimeMethodHandle cache"); 
GC.KeepAlive(methodlnfos); // Запрешаем уборку мусора в кзше 

methodlnfos = null; // Разрешаем уборку мусора в кзше 
Show("After freeing Methodlnfo objects"); 

methodlnfos = methodHandles.ConvertAll<MethodBase>( 
rmh=> MethodBase.GetMethodFromHandle(rmh)); 

Show("Size of heap after re-creating Methodlnfo objects"); 
GC.KeepAlive(methodHandles); // Запрешаем уборку мусора в кзше 

GC.KeepAlive(methodlnfos); // Запрешаем уборку мусора в кзше 

methodHandles = null; // Разрешаем уборку мусора в кзше 

methodlnfos = null; // Разрешаем уборку мусора в кзше 

Show("After freeing Methodlnfos and RuntimeMethodHandles"); 

} 


При построении и вмполнении зтои программм вмводитсл следугогции ре- 
зулБтат: 

Неар size= 85,000 - Before doing anything 
# of methods=48j467 

Heap size= 7,065,632 - After building cache of Methodlnfo objects 

Heap size= 7,453,496 - Holding Methodlnfo and RuntimeMethodHandle cache 

Heap size= 6,732,704 - After freeing Methodlnfo objects 

Heap size= 7,372,704 - Size of heap after re-creating Methodlnfo objects 

Heap size= 192,232 - After freeing Methodlnfos and RuntimeMethodHandles 
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Сериализациеп (serialization) назмваетсн процесс преобразовашш обвекта илп графа 
свнзаннмх обвектов в поток баитов. Соответственно, обратное преобразование на- 
змваетсн десериализациеп (deserialization). НесколБКО примеров применешш зтого 
чрезвмчаино полезного механизма: 

□ Состонние приложешш (граф обпекта) можно легко сохранитг. в фаиле на 
диске или в базе даннћгх и восстановитБ при следугогцем запуске приложенгш. 
ASP.NET сохраннет и восстанавливает состонние сеанса путем сериализации 
и десериализации. 

□ Набор обвектов можно скопироватв в буфер и вставитв в то же или в другое при- 
ложение. Зтот подход исполБзуетси в приложенгшх Windows Forms и Windows 
Presentation Foundation (WPF). 

□ Можно клонироватБ набор обвектов и сохранитв как «резервнуго копиго», пока 
полвзователБ работает с «основнбгм» набором обвектов. 

□ Набор обвектов можно легко передатв по сети в процесс, запугценнвги на другои 
машине. Механизм удаленного взаимодеиствгш платформвг .NET Framework се- 
риализует и десериализует обвектБг, продвигаемБге по значеншо. Зта же техноло- 
ггш исполБзуетсл при передаче обвектов через границвг домена (см. главу 22). 

Кроме того, после сериализации обвектов в поток баитов в памлти понвлнетсн воз- 
можностб дополнителБнои обработки даншлх — например, шифровангш и сжатин. 

НеудивителБно, что многие программистБг проводлт бесчисленнвге часБг за раз- 
работкои кода, вБшолннгогцего зти операции. Однако при зтом соответствугогции 
код сложно и муторно писатв, к тому же он подвержен ошибкам. Разработчикам 
приходитси решатв проблемБг взаимодеиствгш протоколов, несовпаденгш типов 
даннвгх клиента и сервера (например, разнвнг порндок следовангш баитов), об- 
работки ошибок, ссбшок одних обвектов на другие, параметров in и out, массивов 
структур — и зтот список можно продолжатв бесконечно. 

Впрочем, в .NET Framework сугцествует встроеннвпг механизм сериализации 
и десериализации. Зто означает, что все упомннутвге сложнБге проблемБг уже ре- 
шенБг средствами .NET Framework. Разработчик может исполвзоватБ обвектБг до 
сериализации и после десериализации, а всго заботу о том, что происходит между 
зтими двумн процедурами, на себи берет ,NET Framework. 

В зтои главе рассказвгваетсн, как сервис сериализации и десериализации реали- 
зован в .NET Framework. Зти процедурвг определенвг практически дли всех типов 
даннвгх, а следователБно, вам не придетсн предпрггниматв дополнителБНБгх усилии, 
что6бг сделатБ свои типбг сериализуемБши. Впрочем, сугцествугот и типбг, дли ко- 
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тормх подобнан предварителБнан подготовка необходима. К счастБК), механизм се- 
риализации .NET Framework поддерживает расширение, и мбг деталћно рассмотрим 
даннћпг процесс, позволнкнции вбшолннтб различнБге операции при сериализации 
и десериализации обБектов. К примеру, и покажу, как сериализовав одну версшо 
оОЂекта в фаил на диске, десериализоватв его потом в другуго версшо. 

ПРИМЕЧАНИЕ 

В зтои главе в основном рассматриваетса технологил сериализации в среде CLR, 
которап хорошо распознает типн даннБ 1 х CLR и умеет сериализоватц полл обвектов, 
помеченние модификаторами public, protected, internal и даже private, преврашдл их 
в сжатми двоичнб 1 и поток и тем саммм повмшал производителБностБ. Длп сериали- 
зации типов даннмх CLR в поток XML требуетси кпасс System.Runtime.Serialization. 
NetDataContractSerializer. Платформа .NET Framework предлагает и другиетехноло- 
гии сериализации, разработаннме длл взаимодеиствил между CLR-coBMecTHMbiMH 
и С^Р-несовместиммми типами даннмх. В них исполизунотсл класси! System.Xml. 
Serialization.XmlSerializer и System.Runtime.Serialization.DataContractSerializer. 


Практическии пример сериализации/ 
десериализации 

Рассмотрим такои код: 

using System; 

using System.Collections.Generic; 
using System.IO; 

using System.Runtime.Serialization.Formatters.Binaryj 

internal static class QuickStart { 
public static void Main() { 

// Создание графа обБектов длв последунхцеи сериализации в поток 
var objectGraph = new List<String> { 

"Deff", "Kristin"j "Aidan", "Grant" }; 

Stream stream = SerializeToMemory(objectGraph); 

// Обнуллем все длл данного примера 
stream.Position = 0; 
objectGraph = null; 

// Десериализацид обцектов и проверка их работоспособности 
objectGraph = (List<String>) DeserializeFromMemory(stream) ; 
foreach (var s in objectGraph) Console.WriteLine(s); 

} 

private static MemoryStream SerializeToMemory(Object objectGraph) { 

// Конструирование потока, которни будет содержатц 
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// сериализованнме обБек™ 

MemoryStream stream = new MemoryStream( ); 

// Задание форматированил при сериализации 
BinaryFormatter formatter = new BinaryFormatter( ); 

// Заставллем модулц форматированил сериализоватц обцектм в поток 
formatter . Serialize(stream, objectGraph) ; 

// Возврацение потока сериализованнмх обцектов Bbi3biBammeMy методу 
return stream; 

} 

private static Object DeserializeFromMemory(Stream stream) { 

// Задание форматированил при сериализации 
BinaryFormatter formatter = new BinaryFormatter(); 

// Заставллем модулц форматированил десериализоватц обцектн из потока 
return formatter . Deserialize(stream) ; 

} 

} 

Видите, как просто! Метод SerializeToMemory создает обкект System. 
10. MemoryStream. Зтот обкект определиет, куда следует поместитБ сериализованнми 
блок баитов. Затемметод конструирует обвект BinaryFormatter (расположеннми 
в пространстве имен System . Runtime . Serialization . Formatters. Binary). Моду- 
лем форматированим (formatter) назмваетсн тип (он реализует интерфеис System . 
Runtime.Serialization.IFormatter), умегошии сериализоватБ и десериализо- 
ватБ граф обЂектов. В библиотеку FCL вклгоченм два модулн форматированин: 
BinaryFormatter (исполЂзуетсл в показанном фрагменте кода) и SoapFormatter 
(находншиисн в пространстве имен System . Runtime . Serialization . Formatters. 
Soap и реализованнми в сборке System . Runtime .Serialization. Formatters . 
Soap.dll). 

ПРИМЕЧАНИЕ 

Начинав c версии 3.5, в .NET Framevvork класс SoapFormatter считаетсл устаревшим 
и не рекомендуетсл к исполвзованик). Однако его имеет сммсл применатц при отладке 
кода сериализации, так как он создает доступнми длл чтенил текст в формате XML. 
Если в вмходном коде Bbi хотите восполвзоватцсл механизмами ХМ1-сериализации 
и ХМ1-десериализации, обратитесц к классам XmlSerializer и DataContractSerializer. 


Длн сериализации графа обвектов достаточно вмзватЂ метод Serialize модулн 
форматировании и передатЂ ему, во-первмх, ссмлку на обвект потока ввода-вм- 
вода, во-втормх, ссмлку на сериализуемми граф. Поток ввода-вмвода указмвает, 
куда следует поместитБ сериализуемме баитм. Его ролБ может игратБ обвект 
лгобого типа, производного от абстрактного базового класса System.IO.Stream. 
Зто означает, что граф может 6мтб сериализован в тип MemoryStream, FileStream, 
NetworkStream и т. п. 
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Во втором параметре метода Serialize пвлнетсн ссмлка на обвект лгобого типа: 
Int32, String, DateTime, Exception, List<String>, Dictionary<Int32,DateTime> 
и т. п. Обвект, на которми ссмлаетси параметр objectGraph, может, в cboio очередБ, 
содержатћ ссбшки надругие обБектБт К примеру, параметр objectGraph 6 б 1 тб ссбш- 
Koii на коллекцшо обвектов, которме, в cboio очередв, могут ссбшдтбси на другие 
обБектБг Метод Serialize сериализует в поток все о 6 бсктб 1 графа. 

МодулБ форматированип «знает», как сериализоватв весБ граф, ссБ1лалсБ на 
описБшагогцие тип каждого обвекта метаданнБШ. Длн отслеживанин состопнин 
зкземплпрнБ1х полеи в типе каждого обвекта в процессе сериализации метод 
Serialize исполвзует отражение. Если какие-то из полеи ссБшаготси на другие 
обБектБц метод сериализует и их. 

Модули форматированин исполвзугот хорошо проработаннБ1е алгоритмБг На- 
пример, они знагот, что каждпш обвект в графе должен сериализоватБСп всего один 
раз. Благодари зтому при перекрестнои ссвшке двух обвектов модулв форматиро- 
ванин не входит в бесконечнвш цикл. 

В моем методе SerializeToMemory при возврагцении управленин методом 
Serialize обвект MemoryStream просто возврашаетсн вБШБшакнцему коду. При- 
ложение исполкзует содержимое зтого неструктурированного массива баитов тем 
способом, которвш считает необходимБш. Например, оно может сохранитп массив 
в фаиле, скопироватв в буфер обмена, переслатв по сети и т. п. 

Метод DeserializeFromStream преврашает поток ввода-ввшода обратно в граф 
обвекта. Зта операцин егце прогце сериализации. В моем коде 6 бш сконструирован 
обвект BinaryFormatter, после чего оставалосв вБИватБ его метод Deserialize. 
Зтот метод берет в качестве параметра поток ввода-ввшода и возврагцает ссвшку 
на корневои обвект десериализованного графа. 

При зтом внутри метод Deserialize исследует содержимое потока, создает 
зкземплирБ1 всех обнаруженнБ1х в потоке обвектов и инициализирует все их, при- 
сваиваи им значенип, которвго граф обвекта имел до сериализации. Обвшно затем 
следует приведение ссбшки на возврагценнБп! методом Deserialize обвект к типу, 
которкш ожидает увидетБ приложение. 

ПРИМЕЧАНИЕ 

Перед вами интереснБш и полезнБш метод, исполБзукиции сериализацикз длл соз- 

данил глубокои копии (клона) обвекта: 

private static Object DeepClone(Object original) { 

// Создание временного потока в памлти 

using (MemoryStream stream = new MemoryStream()) { 

// Созданин модулл форматированил длл сериализации 
BinaryFormatter formatter = new BinaryFormatter( ); 

// Зта строка опишваетсл в разделе "Контекстн потока ввода-внвода" 
formatter.Context = new StreamingContext(StreamingContextStates.Clone); 

// Сериализацил графа обБекта в поток в памнти 
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formatter . Serialize(streamj original) ; 

// Возврашение к началу потока в памлти перед десериализацеи 
stream.Position = 0; 

// Десериализацип графа в новии набор обцектов и возврацение 
// корнл графа (деталцнои копии) вмзшагацему методу 
return formatter . Deserialize(stream) ; 

} 


Здесћ л хотел бм добавитћ несколБКО замечании. Во-первмх, следует следитБ за 
тем, что6б1 сериализацин и десериализацин производиласБ одним и тем же модулем 
форматированин. К примеру, недопустим код, в котором сериализацин графа обвекта 
производитсн модулем SoapFormatter, в то времн как десериализацшо осупдествлн- 
ет уже BinaryFormatter. Если метод Deserialize не в состоинии расшифроватв 
содержимое потока, генерируетсл исклгочение System.Runtime.Serialization. 
SerializationException. 

Во-вторБ1х, хотелосБ 6 б 1 упомннутБ о возможности и полезности сериализации 
набора графов обвектов в единвш поток. Например, пустн у нас естн два опреде- 
ленин классов: 

[Serializable] internal sealed class Customer {/*...*/} 

[Serializable] internal sealed class Order {/*...*/} 

Тогда в основном классе нашего приложенил можно определитв следугогцие 
статические поли: 

private static List<Customer> s_customers = new List<Customer>(); 
private static List<Order> s_pendingOrders = new List<Order>(); 
private static List<Order> s_processedOrders = new List<Order>(); 

Теперн при помогци показанного далее метода можно сериализоватБ состонние 
нашего приложенин в единвш поток: 

private static void SaveApplicationState(Stream stream) { 

// Конструирование модулл форматированил длн сериализации 
BinaryFormatter formatter = new BinaryFormatter( ); 

// Сериализацил всего состолнин приложенил 
formatter.Serialize(stream, s_customers) ; 
formatter.Serialize(stream, s_pendingOrders); 
formatter.Serialize(stream, s_processedOrders); 

} 


Метод, исполБзуемБш длл восстановлении состоинин приложении, вб 1 гллдит 
примерно так: 

private static void RestoreApplicationState(Stream stream) { 

// Конструирование модулл форматированил сериализации 
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BinaryFormatter formatter = new BinaryFormatter( ); 

// Десериализацип состолнил приложенип (виполнлетсл в том же 
// порлдке, что и сериализацил) 

s_customers = (List<Customer>) formatter.Deserialize(stream); 

s_pendingOrders = (List<Order>) formatter.Deserialize(stream); 

s_processedOrders = (List<Order>) formatter.Deserialize(stream); 

} 


Третии тонкии момент, на которми хотелосћ бм указатБ, свнзан со сборками. При 
сериализации обвекта в поток записмвакзтси полное ими типа и определнкпцан его 
сборка. По умолчаншо BinaryFormatter вмдает полнми идентификатор сборки, 
в которми входит ее полное ими (без расширенин), номер версии, измк, регионалБ- 
нме параметрм и открмтми к. поч. Десериализун обвект, модулБ форматированин 
берет идентификатор сборки и обеспечивает ее загрузку в вмполннкзгцииси домен 
при помонда метода Load класса System.Reflection.Assembly (о нем шла речБ 
в главе 23 ). 

После загрузки сборки модулн форматировангш игцет в нем тип, совпадагогции 
с типом десериализованного обвекта. Если сборка не содержит такого типа, генери- 
руетси исклгочение, и далБнеишал десериализацгш обвектов не вмполннетси. При 
обнаружении же нужного типа создаетсл его зкземплир, и полн зтого зкземплира 
инициализируготси значенгшми, содержагцимисн в потоке. В случалх, когда поли 
типа не полностбго совпадагот с именами полеи, считаннБши из потока, генериру- 
етсч исклгочение SerializationException и далћнеишаи десериализацгш обвектов 
приостанавливаетси. Механизмвг, позволнгогцие переопределитв такое поведение, 
МБ1 обсуДИМ ЧуТБ ПОЗЖС. 

ВНИМАНИЕ 

НекоторБ 1 е расширпемБ 1 е приложенич исполбзу10т длч загрузки сборки метод 
Assembly.LoadFrom, а затем конструирукзт обБектм из наиденнц|х в загруженнои 
сборке типов. Такие обвектБ 1 могут без проблем сериализоваљсч в поток. Однако при 
обратнои процедуре модулБ форматированич питаетсч загрузитц сборку, визмвач 
метод Load кпасса Assembly вместо метода LoadFrom. В болцшинстве случаев CLR не 
может наити фаил сборки и генерирует исклкзчение SerializationException. Такое по- 
ведение зачастукз становитсп скзрпризом длч разработчиков. Ведц после корректнои 
сериализации они ожидакзт такои же корректнои десериализации. 

Если ваше приложение сериализует обнекти, типн которц|х определени в сборке, 
загружаемои методом Assembly.LoadFrom, рекомендуга вам реализоватц метод 
с сигнатурои, совпадакзидеи с сигнатурои делегата System.ResolveEventHandler, 
а перед вб!зовом метода Deserialize зарегистрироватц зтот метод с собнтием 
AssemblyResolve класса System.AppDomain. (Послетого как метод Deserialize вернет 
управленич, отмените регистрацикз метода.)ТеперБ, если модулцформатированил не 
сможет загрузитБ сборку, CLR внзовет ваш метод ResolveEventHandler. В него будет 
передан идентификатор не загруженнои сборки. Метод извлечет оттуда имч фаила 
и исполБзует его дпч построенич маршрута доступа к нужнои сборке. После зтого 
будет вБ13ван метод Assembly.LoadFrom, 4to6n загрузитц сборку и вернутБ итоговукз 
ссБшку на нее из метода ResolveEventHandler. 
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Итак, мм рассмотрели основм сериализации и десериализации графов обвектов. 
Пришло времи узнатБ, каким образом определнтБ собственнме сериализуемме 
типм, а также рассмотретБ механизмм, позволнкнцие получитБ дополиителБНБ1и 
контролБ над сериализациеи и десериализациеи. 


Сериализуемне типн 

В процессе проектированин типа разработчик должен приннтБ сознателБное реше- 
ние, разрешатБ или нет сериализациго зкземплиров типа. По умолчаниго сериализа- 
ции не допускаетсл. К примеру, следугогции код не работает ожидаемБш образом: 

internal struct Point { public Int32 х, у; } 

private static void OptInSerialization() { 

Point pt = new Point { х = 1, у = 2 }; 
using (var stream = new MemoryStream()) { 

new BinaryFormatter().Serialize(stream, pt); // исклтчение 

// SerializationException 

} 

} 


Если запуститБ такои код, метод Senialize вБвдаст исклгочение System . Runtime . 
Serialization . SenializationException. Дело в том, что разработчик типа Point не 
указал в нвном виде, что обвектБ1 данного типа можно сериализоватБ. РешитБ про- 
блему можно при помоши настраиваемого атрибута System . SenializableAttnibute, 
примененного к типу следугогцим образом (обратите внимание, что даннБш атрибут 
принадлежит пространству имен System, а не System . Runtime . Senialization): 

[Serializable] 

internal struct Point { public Int32 х, у; } 

Если теперв снова скомпоноватБ и запуститв приложение, все начнет нормалБ- 
но работатв, а обвектБ1 типа Point будут сериализоватБСн в поток. Сериализул 
граф, модулв форматированин провериет способноств к сериализации каждого из 
обвектов. Если хоти 6bi один из обвектов не поддерживает сериализациго, метод 
Senialize генерирует исклгочение SenializationException. 

ПРИМЕЧАНИЕ 

При сериализации графа обвектов некоторБ 1 е типб1 могут оказатБСл сериализуемБ!- 
ми, а некоторБ 1 е — нет. По причинам, свлзанннм с производителБностБ 10 , модулБ 
форматированил перед сериализациеи не проверлет возможностб зтои операции 
длл всех обвектов. А значит, может возникнутБ ситуацил, когда некоторме обвектБ 1 
окажутсл сериализованнБ 1 ми в потокдо полвленил исклкзченил SerializationException. 
В резулвгате в потоке ввода-внвода оказБ 1 вак)тсл поврежденнне даннБ 1 е. ЖелателБ- 
но, что6б1 код приложенил умел корректно восстанавливатисл послетакои ситуации. 
Зтого можно добитвсл, например, сериализул обЂектн сначала в MemoryStream. 
Если процедурадпл всех обЂектов проидетуспешно, баитм из MemoryStream можно 
скопироватЂ в лкзбои другои поток ввода-вмвода (то ecTb в фаил или в ceTb). 
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Настраиваемми атрибут SerializableAttnibute может применнтБСн то.п.ко 
к ссмлочнмм типам (классам), значиммм типам (структурам), перечислиммм 
типам (перечислениим) и делегатам (имеите в виду, что перечислимме типм и де- 
легатм всегда сериализуемм, позтому к ним не нужно нвно применптБ атрибут 
SerializableAttribute). ДаннБ1и атрибут не наследуетси производнБши типами. 
Соответственно, в следугогцем примере обЂект Person может 6б1тб сериализован, 
а вот обвект Employee — нет: 

[Serializable] 

internal class Person { ... } 
internal class Employee : Person { ... } 

Проблема может 6б1тб решена применением атрибута SerializableAttribute 
к типу Employee: 

[Serializable] 

internal class Person { ... } 

[Serializable] 

internal class Employee : Person { ... } 

B зтом случае проблема решаласк легко. А вот обратнаи ситуации — когда 
требуетси определитв тип, производнБи! от базового и не имегогции атрибута 
SerializableAttribute — уже не столб тривиалБна, однако сделано намеренно; 
если базовБш тип не допускает сериализации своих зкземплнров, его полн нелвзи 
будет подвергнутБ зтои процедуре, ведБ базовБи! обвект фактически нвлиетсн 
частвго производного. Именно позтому классу System.Object назначен атрибут 
SerializableAttribute. 

ПРИМЕЧАНИЕ 

В обш,ем случае 6 олбшинство типов лучше делатБ сериализуемБ1ми. Хотч бн потому, 
что зто дает полБЗОвателчм болБшуно гибкостБ. Однако следует учитмватБ, что при 
сериализации читактгсч все полч обвекта вне зависимости от того, с каким модифи- 
катором они бмли обБнвленм — public, protected, internal или private. Позтому если 
тип содержит конфиденциалБнме или заш,ииденнБ1е даннне (например, пароли), врчд 
ли стоит делатБего сериализуеммм. 

Если вм работаете с типом, не предназначеннмм длч сериализации, а его исходнми 
код недоступен, не все потерчно. ЧутБ позже л расскажу, как организоватБ сериа- 
лизациго такого типа. 


Управление сериализациеи 
и десериализациеи 

После назначенип типу настраиваемого атрибута SerializableAttribute все зкзем- 
плнрв! его полеи (открБПБге, закрБ1ТБге, загцигценнБге и т. п.) становитси сериализу- 


674 Глава 24. Сериализацил 


емБши 1 . Впрочем, в типе можно указатБ некоторБге зкземплнрБ1 как не подлежатцие 
сериализации. В обшем случае зто делаетсн по двум причинам: 

□ Поле содержит информациго, становипдугосп недеиствителвнои после десери- 
ализации. Например, сгода относлтси o6'i>eici bi, содержатцие дескрипторБ1 обв- 
ектов идра Windows (таких, как фаилвц процессБц потоки, мБГОтексБц собБтш, 
семафорБ1 ит.п.). Их десериализацин в другои процесс или на другуго машину 
бессмБШленна, так как дескрипторБ1 ндра Windows привнзанБ1 к конкретному 
процессу. 

□ Полн содержат легко обновлнемуго информациго. В зтом случае сделав их не под- 
лежагцими сериализации, bbi уменвшите обвем передаваемБ1х даннБ1Х, а значит, 
iiobbicine производителБностБ. 

В показанном далее фрагменте кода с помогцбго настраиваемого атрибута System . 
NonSerializedAttnibute помечаготсн полн, не подлежагцие сериализации (имеи- 
те в виду, что зтот атрибут определен в пространстве имен System, а не System. 
Runtime.Senialization): 

[Serializable] 
internal class Circle { 
private Double m_radius; 

[NonSerialized] 
private Double m_area; 

public Circle(Double radius) { 
m_radius = radius; 

m_area = Math.PI * m_radius * m_radius; 

} 


} 

ОбЂектБ 1 класса Cincle допускагот сериализациго, но модулБ форматировангш 
сериализует толбко значенгш полн m_nadius. Значенгш полн m_anea не сериализу- 
10 ТСИ, так как зтому полго 6 бш назначен атрибут NonSenializedAttnibute. Его на- 
значагот толбко полим типа, но деиствие атрибута распространнетсл на полн и при 
наследовании другим типом. Конечно, в пределах типа он может 6 bitb назначен 
целому набору полеи. 

Предположим, в нашем коде обвект Circle конструируетсл следугогцим об- 
разом: 

Circle с = new Circle(10); 


1 В C# внутри типов, помеченнмх атрибутом [Serializable], не стоит определлтв автоматиче- 
ски реализуемћге своиства. Дело в том, что имена полеи, генерируемћге компиллтором, могут 
меннтБсл после каждои следуготцеи компиллции, что сделает невозможнои десериализациго 
зкземплнров типа. 
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Полго m_area бмло присвоено значение, равное примерно 314,159. Но при 
сериализации обвекта в поток ввода-вмвода записмваетсл толбко значение поли 
m_radius, равное 10. Именно зтого мм и добивалисБ, но при десериализации потока 
обратно в обвект Circle возникает проблема. Поле m_radius получит значение 10, 
а вот поле m_area станет равнмм 0, а не 314,159! 

Следуклции фрагмент кода показмвает, как решитБ зту проблему: 

[Serializable] 
internal class Circle { 
private Double m_radius; 

[NonSerialized] 
private Double m_area; 

public Circle(Double radius) { 
m_radius = radius; 

m_area = Math.PI * m_radius * m_radius; 

} 

[OnDeserialized] 

private void OnDeserialized(StreamingContext context) { 
m_area = Math.PI * m_radius * m_radius; 

} 

} 

Tenepb обвект Circle снабжен методом c настраиваеммм атрибутом System. 
Runtime .Serialization .OnDeserializedAttribute 1 . При десериализации зкзем- 
плнра типа модулБ форматированин провериет наличие в типе метода с даннмм 
атрибутом. При далБнеишем вмзове метода все сериализуемме поли получат кор- 
ректнме значенин и к тому же станут доступнмми длн дополнителћнмх операции, 
без котормх невозможна полнан десериализацин обвекта. 

В модифицированнои версии обвекта Circle и заставил метод OnDeserialized 
вмчислитб плогцадћ круга на основе значенин полн m_radius, помегцан резулшат 
в поле m_area. В резулшате зто поле получает нужное нам значение 314,159. 

Кроме настраиваемого атрибута OnDeserializedAttribute в пространстве 
имен System . Runtime . Serialization определенм также настраиваемме атрибутм 
OnSerializingAttribute, OnSerializedAttribute и OnDeserializingAttribute, 
применив которме к методам нашего типа мм получаем дополнителБнми контролБ 
над сериализациеи и десериализациеи. Пример класса, применнкнцего к методу 
все зти атрибутм: 

[Serializable] 
public class МуТуре { 

Int32 х, у; [NonSerialized] Int32 sum; 

продолжение # 

1 Применение настраиваемого атрибута System.Runtime.Serialization.OnDeserialized 
лвллетсн более предпочтителвнвш в случае ввхзова метода при десериализации обвекта, 
чем реализацин типом метода OnDeserialization интерфеиса System.Runtime.Serialization. 
IDeserializationCallback. 
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public MyType(Int32 х, Int32 у) { 
this.x = х; this.y = у; sum = х + у; 

} 

[OnDeserializing] 

private void OnDeserializing(StreamingContext context) { 

// Пример. Присвоение полнм значении по умолчаник) в новои версии типа 

} 

[OnDeserialized] 

private void OnDeserialized(StreamingContext context) { 

// Пример. Инициализацин временного состолнив полеи 
sum = х + у; 

} 

[OnSerializing] 

private void OnSerializing(StreamingContext context) { 

// Пример. Модификацил состолнин перед сериализациеи 

} 

[OnSerialized] 

private void OnSerialized(StreamingContext context) { 

// Пример. Восстановление лтбого состоннин после сериализации 

} 

} 


Метод, определеннми с зтими четмрБми атрибутами, должен приниматБ един- 
ственнми параметр StreamingContext (подробно мм поговорим о нем позже) 
и возврагцатБ значение типа void. Ими метода может 6 мтб произволБНБш. 06ђнв- 
лнтб его следует с модификатором private, что 6 б 1 исклгочитб вбиов из о 6 б 1 чного 
кода; модули форматировангш имегот достаточнвш уровенБ прав, чтобвг вБгзвшатБ 
private -методБ!:. 

ПРИМЕЧАНИЕ 

При сериализации набора обвектов модулц форматированил сначала вБ13Б1вает 
все методн обБектов, помеченнБ 1 е атрибутом OnSerializing. Затем сериализукзтсл 
полл всех обвектов, последнеи наступает очередБ методов обвектов с атрибутом 
OnSerialized. Аналогично при десериализации набора обвектов модулц форматиро- 
ванил вБ13нвает сначала методБ! обЂектов, помеченнБ 1 е атрибутом OnDeserializing, 
затем десериализует полл обвектов, в завершение вБ13швал методм обвектов 
с атрибутом OnDeserialized. 

Следует учитБ 1 ватц, что при десериализации, обнаружив тип с помеченнмм атри- 
бутом OnDeserialized методом, модулБ форматированиа добавллет ссшлку на зтот 
обвект во внутреннии список. Зтот список просматриваетсл в обратном порчдке 
после десериализации всех обБектов, и модулБ форматированил вшзБ 1 вает метод 
с атрибутом OnDeserialized длл каждого обЂекта. При зтом происходит корректное 
присвоение значенил всем сериализуемшм поллм и предоставллетсл доступ ко всем 
необходимшм длл полнои десериализации обЂекта операцилм. Обратнши порчдок 
внзова методов обеспечивает сначала десериализацик) внутренних обЂектов, а уж 
затем десериализукзтсл вклкзча!Ош,ие их в себл внешние обЂектш. 
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К примеру, представате коллекцикз (Hashtable или Dictionary), длл управленил набо- 
ром злементов исполвзукшдукз хзш-таблицу. Тип обвектов зтои коллекции реализует 
метод с атрибутом OnDeserialized. Хотл коллекцил десериализуетсл первои (передее 
злементами), указаннв 1 и метод вмзв 1 ваетсл в конце (после аналогичнмх методов дпл 
всехзлементов). Зто позволлет злементам завершитв десериализацик), корректно 
инициализировав все полл, и правилвно вв 1 числитвхзш-код. Затем коллекцил создает 
внутреннии сегмент памлти и с noMombio хзш-кода злементов помеидает их в зтот 
сегмент. Подробнђ 1 и пример с классом Dictionary Bbi наидете в зтои главе далее. 


Если сериализоватћ зкземплнр типа, добавитћ к нему новое поле и попБгтатвси 
десериализоватБ не содержатции зтого полн обвект, модулк форматированин ввгдаст 
исклгочение SenializationException с сообгцением о том, что даннкге в десериа- 
лизуемом потоке содержат неверное количество членов. Подобнан проблема часто 
возникает при изменении версии, так как при переходе от старои версии к типу 
добавлиготси новвге полн. К счастнго, можно восполБЗОватБСи атрибутом System. 
Runtime.Senialization.OptionalFieldAttnibute. 

Атрибут OptionalFieldAttnibute назначаетсл каждому новому полго, добав- 
лиемому к типу. Встретив поле с таким атрибутом, модулв форматированин не 
генерирует исклгочение SenializationException, даже если даннвге в потоке не 
содержат такого полн. 


Сериализацил зкземпллров типа 

В зтом разделе подробно рассматриваетсн тема сериализации полеи обвекта. Зта 
тема поможет вам поннтб нетривиалБНБге приемБг сериализации и десериализации, 
которБгм посвнгцен остаток даннои главБк 

Длн облегченил работБ 1 модулл форматированил в FCL вклгочен тип 
FonmattenSenvices из пространства имен System.Runtime.Senialization. Он 
обладает толбко статическими методами и не допускает создангш зкземплнров. Вот 
каким образом модулв форматированин автоматически сериализует обвект, типу 
которого назначен атрибут SenializableAttnibute: 

1. Модулв форматированил вБгзвшает метод GetSenializableMembens класса 
FonmattenSenvices: 

public static MemberInfo[] GetSerializableMembers( 

Туре type, StreamingContext context); 

Длн полученгш открБ1ТБ1х и закрБ1ТБ1х зкземплнрнБгх полеи (исклгочаи поли 
с атрибутом NonSenializedAttnibute) зтот метод исполБзует отраженгш. Он 
возврагцает массив обвектов Membenlnfo — по одному обвекту на каждое сери- 
ализуемое зкземплирное поле. 

2. Полученнвш массив обвектов System . Reflection .Membenlnfo передаетсл ста- 
тическому методу GetObjectData класса FonmattenSenvices: 

public static Object[] GetObjectData(Object obj, MemberInfo[] members); 
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Зтот метод возвратцает массив Object, в котором каждми злемент определлет 
значение полн сериализованного обвекта. Массивм Object и Memberlnfo парал- 
лел i,i n,i. То естБ нулевои злемент массива Object представлиет собои значение 
члена, фигурирукицего в массиве Memberlnfo под нулевмм индексом. 

3. М одул i, форматированип записмвает в поток идентификатор сборки и полное 
имн типа. 

4. М одул i, форматировангш пересчитмвает злементм двух массивов, записмваи 
в поток ввода-вмвода имл каждого члена и его значение. 

А вот как вмгллдит процедура автоматическои десериализации обвекта, тип 

которого помечен атрибутом SerializableAttribute: 

1. М одул I, форматировангш читает из потока ввода-вмвода идентификатор сбор- 
ки и полное ими типа. Если сборка егце не загружена в домен, он загружает ее 
(как описано ранее). При невозможности загрузки поивлиетсл исклгочение 
SerializationException, и десериализацгш обвекта останавливаетси. Если же 
сборка успешно загружена, моду. п, форматировангш передает статическому 
методу GetTypeFromAssembly класса FormatterServices ее идентификатор 
и полное имн типа: 

public static Туре GetTypeFromAssembly(Assembly assem, String name); 

Метод возврагцает обЂект System.Type, содержагции информациго о типе 
десериализованного обЂекта. 

2. МодулЂ форматированип вмзмвает статическии метод GetUninitializedObject 
класса FormatterServices: 

public static Object GetUninitializedObject(Type type); 

Зтот метод вмделлет памлтЂ под новми обвект, но не вмзмвает его конструк- 
тор. При зтом все баитм обвекта инициализируготси значением null или 0. 

1. Тем же способом, что и ранвше, модулЂ форматировангш создает и инициа- 
лизирует массив Memberlnfo, вмзмвап метод GetSerializableMembers класса 
FormatterServices. Даннми метод возврагцает набор полеи, которме бмли 
сериализованм и тепери нуждаготсл в десериализации. 

2. Из содержагцихсл в потоке ввода-вмвода даннмх модулЂ форматированин соз- 
дает и инициализирует массив Object. 

3. Ссмлки на толђко что размегценнми в памлти обвект, массив Memberlnf о, и па- 
раллелЂнми ему массив Object со значенинми полеи передаготсл статическому 
методу PopulateObjectMembers класса FormatterServices: 

public static Object PopulateObjectMembers( 

Object obj, MemberInfo[] members, Object[] data); 

Зтот метод перебирает злементм массивов, ггнициализирул каждое поле 
соответствугогцим значением. В резулвтате обвект оказмваетси полностђго де- 
сериализованнмм. 
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Управление сериализованнмми 
и десериализованнБ1ми даннмми 

Как уже упоминалосћ в зтои главе, управлитБ процессами сериализации и десе- 
риализации лучше всего при помогци атрибутов OnSerializing, OnSerialized, 
OnDeserializing, OnDeserialized, NonSerialized и OptionalField. Однако иногда 
встречаготси сценарии, дли котормх даннмх атрибутов недостаточно. Кроме того, 
работа модулеи форматировангш основана на отражении, а зто — не бмстрми про- 
цесс, значителћно замедлигогции сериализациго и десериализациго обвектов. Чтобм 
получитг> полнбш контролБ над даннћши процедурами и исклгочитб отражение, тип 
может реализоватБ интерфеис System . Runtime . Serialization . ISerializable, 
определнемБпг следугогцим образом: 

public interface ISerializable { 

void GetObjectData(SerializationInfo info, StreamingContext context)j 

} 


Внутри зтого интерфеиса имеетсн всего один метод — GetObjectData. Но 
болБшинство реализугогцих его типов реализугот также специалБНБш конструктор, 
KOTopbiri кратко описан далее. 

ВНИМАНИЕ 

Основнои проблемои интерфеиса ISerializable авлпетса тот факт, что его должнб! ре- 
ализовиваљ и все производнБ1етипи, гарантированно вБ1зивап метод GetObjectData 
базового класса и специалБНБ1и конструктор. Кроме того, реализацикз данного ин- 
терфеиса типом нелБза отменитБ, потому что зто приведет к потере совместимости с 
производнмми типами. Впрочем, ддл изолированнмхтипов реализацил интерфеиса 
ISerializable всегда происходит без проблем. Кроме того, избежатБ потенциалБнмх 
неприптностеи, свлзанних с даннмм интерфеисом, можно при помош,и описанних 
ранее настраиваемих атрибутов. 


ВНИМАНИЕ 

Интерфеис ISerializable и специалБНБм конструктор предназначенм длч модулл 
форматированил. Визов метода GetObjectData другим кодом потенциалБно может 
привести к возвраш,ени10 конфиденциалБнои информации. Другои код может при зтом 
создатБ обвект, передакдции поврежденние данние. Позтому методу GetObjectData 
и специалБному конструктору рекомендуетсл назначитБ следуклции атрибут: 

[SecurityPermissionAttribute(SecurityAction.Demand, SerializationFormatter = 

true) ] 


Прп сериализации графа модулд форматировангш просматривает каждћпг обвект. 
Если тип обЂекта реализует интерфеис ISerializable, модулБ форматировангш 
игнорирует все полБЗОвателБСКие атрибутБ1 и конструирует новбпг обвект Sy stem . 
Runtime.Serialization.Serializationlnfo, содержагции реалБНБпг набор всех 
подлежагцих сериализации значении обвекта. 
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В конструируемћш обЂект Serializationlnfo модулБ форматированин пере- 
дает два параметра: Туре и System . Runtime . Senialization . IFonmattenConventer. 
IlepBbni параметр идентифицирует сериализуемћш обвект. Дли уникалБнои иден- 
тификации типа требуетси два фрагмента даннБ1х: строковое ими типа и иденти- 
фикатор его сборки (вклкзчагогции имн сборки, ее версшо, регионалБНБге стандартБ1 
и открБ 1 ТБш клгоч). Готовбш обвект Senializationlnfo получает полное имн типа 
(запросив своиство FullName), сохрашш его в закрБггом поле. Дли получешш пол- 
ного имени типа исполБзуите своиство FullTypeName класса Senializationlnfo. 
АналогичнБ 1 м образом конструктор получает определшшцуго тип сборку (за- 
прашиваи сначала своиство Module класса Туре, затем своиство Assembly класса 
Module и, наконец, своиство FullName класса Assembly), сохрании полученнуго 
строку в закрБ 1 том поле. Длл полученин идентификатора сборки исполБзуите поле 
AssemblyName класса Serializationlnfo. 

ПРИМЕЧАНИЕ 

ЗадатБ своиства FullTypeName и AssemblyName класса Serializationlnfo не всегда 
возможно. Длч измененил типа после сериализации рекомендуетсч вБ13ватБ метод 
SetType класса Serializationlnfo и передатБ ему ссБшку на желаемБ 1 и обБект Туре. Зто 
гарантирует корректностБ задании полного имени и определч 10 шеи сборки. Пример 
применениа данного метода приводитсч далее в зтои главе. 


После создангш и инициализации обвекта Senializationlnfo модулБ форма- 
тированин передает ссбшку на него в метод GetObjectData типа. Именно метод 
GetOb jectData определнет, какан информацгш необходима дли сериализации 
обЂСкта, и добавлнет зту информациго к обвекту Senializationlnf о. Определение 
необходимои длл сериализации информации происходит при помогци однои из 
множества перегруженнБгх версгш метода AddValue типа Senializationlnf о. Дли 
каждого фрагмента даннБгх, которБш Bbi хотите добавитБ, вБгзБшаетси один метод 
AddValue. 

ПоказаннБш далее код демонстрирует, каким образом тип Dictionary<TKey, 
TValue> реализует интерфеисБ 1 ISenializable и IDesenializationCallback, до- 
биваисБ контролн над сериализациеи и десериализациеи своих обвектов: 

[Serializable] 

public class Dictionary<TKey, TValue>: ISerializable, 

IDeserializationCallback { 

// Здесв закрмтме полп (не показаннме) 

private Serializationlnfo m_siInfo; // TonbKO длп десериализации 

// Специалинми конструктор (необходимми интерфеису ISerializable) 

// длл управленип десериализациеи 
[SecurityPermissionAttribute( 

SecurityAction . Demand, SerializationFormatter = true)] 
protected Dictionary(SerializationInfo info, StreamingContext context) { 
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// Во времл десериализации сохраним 
// Serializationlnfo длн OnDeserialization 
m_siInfo = info; 

} 

// Метод управленин сериализациеи 

[SecurityCritical] 

public virtual void GetObjectData( 

Serializationlnfo info^ StreamingContext context) { 

info.AddValue("Version"j m_version); 

info.AddValue("Comparer"j m_comparer., typeof(IEqualityComparer<TKey>)); 
info.AddValue("HashSize"j (m_ buckets == null) ? 0 : m_buckets.Length); 
if (m_buckets != null) { 

KeyValuePair<TKey, TValue>[] аггау = 
new KeyValuePair<TKey, TValue>[Count]; 

CopyTo(array, 0); 
info.AddValue( 

"KeyValuePairs", аггау, typeof(KeyValuePair<TKey, TValue>[])); 

} 

} 

// Метод, внзнваемни после десериализации всех клтчеи/значении обцектов 
public virtual void IDeserializationCallback.OnDeserialization( 

Object sender) { 

if (m_siInfo == null) return; // Никогда не присваиваетсл, 

// возврацение управленил 

Int32 num = m_siInfo.GetInt32("Version" ); 

Int32 num2 = m_siInfo.GetInt32("HashSize"); 
m_comparer = (IEqualityComparer<TKey>) 

m_siInfo.GetValue("Comparer", typeof(IEqualityComparer<TKey>)); 
if (num2 != 0) { 

m_buckets = new Int32[num2]; 

for (Int32 i = 0; i < m_buckets.Length; i++) m_buckets[i] = -1; 
m_entries = new Entry<TKey, TValue>[num2]; 
m_freeList = -1; 

KeyValuePair<TKey, TValue>[] pairArray = ( 

KeyValuePair<TKey, TValue>[]) m_siInfo.GetValue( 

"KeyValuePairs", typeof(KeyValuePair<TKey, TValue>[])); 
if (pairArray == null) 

ThrowHelper.ThrowSerializationException( 

ExceptionResource.Serialization_MissingKeys); 

for (Int32 j = 0; j < pairArray.Length; j++) { 
if (pairArray[j] .Кеу == null) 

ThrowHelper.ThrowSerializationException( 

ExceptionResource.Serialization_NullKey); 

Insert(pairArray[j] .Кеу, pairArray[j].Value, true); 

} 

} else { m_buckets = null; } 


продолжение & 
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m_version = num; 
m_si!nfo = null; 


КаждБш метод AddValue принимает в качестве параметра ими типа Stning и на- 
бор даннБ 1 х. Обћшно зти даннБ1е принадлежат к простБгм значимБш типам, таким 
как Boolean, Chan, Byte, SByte, Intl6, UIntl6, Int32, UInt32, Int64, UInt64, Single, 
Double, Decimal и DateTime. Впрочем, методу AddValue можно передатк ссбшку на 
тип Object, к примеру, Stning. После того как метод GetObjectData добавит всго 
необходимуго дли сериализации информациго, управление возврагцаетси модулго 
форматированин. 

ПРИМЕЧАНИЕ 

ДобавллтБ к типу информацикз сериализации следует толбко с помоидБкз одного из 
перегруженнмх методов AddValue. Длл полеи, тип котормх реализует интерфеис 
ISerializable, нелБза вмзмватБ метод GetObjectData. ЧтобБ 1 добавитБ поле, исполб- 
зуите метод AddValue; модулБ форматированил проследит за тем, чтобм тип полл 
реализовал ISerializable, и вмзовет метод GetObjectData. Если же вм решите вмзватБ 
зтот метод длл описанного ранее полл, при десериализации потока ввода-вмвода 
модулБ форматированил не будет знатБ, что он должен создатБ новбш обвект. 


На зтом зтапе модулв форматировании берет все добавленнвш к обвекту 
Senializationlnfo значенин и сериализует их в поток ввода-ввшода. Обратите 
внимание, что методу GetObjectData передаетсл егце один параметр: ссвшка на 
обвект System.Runtime.Senialization.StneamingContext. Зтот параметр игно- 
рируетсл методом GetObjectData болБшинства типов, позтому здесв мбг на нем 
останавливатБСи не станем, а рассмотрим его отделнно ближе к концу главБг 

Итак, вб 1 уже знаете, как задатн всго необходимуго дли сериализации информа- 
циго. Пришла пора рассмотретв процедуру десериализации. Извлекан обвект из 
потока ввода-вБшода, модулБ форматированин ввгделнет дли него место в памлти 
(вБ13Бшан статическии метод GetUninitializedObject типа System . Runtime . 
Senialize. FonmattenSenvices). ИзначалБно всем полим обвекта присваиваетси 
значение 0 или null. Затем модулв форматированин провернет, реализует ли тип 
интерфеис ISenializable. В случае положителвного резулнтата проверки модулв 
пБггаетси вБгзватБ специалБНБги конструктор, параметрБг которого идентичнБг па- 
раметрам метода GetObjectData. 

Длн классов, помеченнвгх модификатором sealed, зтот конструктор рекомен- 
дуетси о6бпвлптб с модификатором pnivate. Зто предохранит код от случаиного 
вБгзова и повбгсит уровенБ безопасности. Также конструктор можно пометитн мо- 
дификатором pnotected, предоставив доступ к нему толбко производнБш классам. 
Впрочем, модули форматированин могут ввгзвшатБ его вне зависимости от того, 
каким именно способом 6бш обЂпвлен конструктор. 

Конструктор получает ссвшку на обвект Senializationlnfo, содержагции все 
значенин, добавленнвге на зтапе сериализации. Он может вБгзБшатБ лгобБге методБ! 
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GetBoolean,GetChar,GetByte,GetSByte, Getlntl6, GetUIntl6, Getlnt32, GetUInt32, 
Getlnt64, GetUInt64, GetSingle,GetDouble, GetDecimal,GetDateTime, GetString 
и GetValue, передавал им строку c именем, которое исполБЗОвалосв при сериали- 
зации значенин. Значенин, возврапдаемме зтими методами, затем инициализиругот 
полн нового обвекта. 

При десериализации полеи обвекта нужно вмзватБ метод Get с тем же саммм 
типом значенин, которое бмло передано методу AddValue в процессе сериализации. 
Другими словами, если метод GetObjectData передал в метод AddValue значение 
типа Int32, метод Getlnt32 должен вмзмватмш дли значенгш зтого же типа. Если 
значение в потоке ввода-вмвода отличаетсн от того, которое вм пмтаетесБ получитБ, 
модулБ форматированин попБ1таетсл восполБЗОватБСн обвектом IFormatterConvert 
длл <<приведешш>> к нужному типу значенгш в потоке ввода-ввшода. 

При конструировании обвекта Serializationlnfo ему передаетси обвект типа, 
реализугошего интерфеис IFormatterConverter. Так как за конструирование от- 
вечает модулв форматировангш, он ввгбирает нужнБпг тип IFormatterConverter. 
Модули BinaryFormatter и SoapFormatter разработки Microsoft всегда конструиру- 
готзкземшшр типа System. Runtime.Serialization . FormatterConverter. ВвгбратБ 
длл зтои цели другои тип IFormatterConverter не удастсл. 

Тип FormatterConverter исполБзует статические методБ 1 класса System. 
Convert длн преобразовангш значении между базоввши типами, например из Int32 
в Int64. Но при необходимости преобразовангш между произволвнБши типами 
FormatterConverter вБ13Бшает метод ChangeType класса Convert длн приведешш 
сериализованного (или исходного) типа к интерфеису IConvertible. После зто- 
го вБ13Бшаетсл подходигции интерфеиснБш метод. СледователБно, если о 6 ђсктб 1 
сериализуемого типа требуетсл десериализоватБ как другои тип, нужно, что 6 бг 
ББгбраннБп! тип реализовБшал интерфеис IConvertible. Обратите внимание, что 
обвект FormatterConverter исполБзуетсл толбко при десериализации обвектов 
и при вБгзове метода Get, тип которого не совпадает с типом значенгш в потоке 
ввода-вБшода. 

Вместо одного из многочисленнБ 1 х методов Get специалвнБШ конструктор 
может ББгзватБ метод GetEnumerator, возврагцагогции обвект System . Runtime . 
Serialization . SerializationlnfoEnumerator, при помогци которого можно 
перебратв все значенгш внутри обвекта Serializationlnfo. Каждое из перечис- 
леннБгх значении представлнет собои обвект System . Runtime . Serialization . 
SerializationEntry. 

Разумеетсл, никто не запрегцает вам создаватв собственнБге типбц производнБге 
от типа, реализугогцего метод GetObjectData класса ISerializable, а также спе- 
циалвнБШ конструктор. Если ваш тип реализует также интерфеис ISerializable, 
дли корректнои сериализацгш и десериализацгш обвекта ваши реализацгш метода 
GetOb jectData и специалБного конструктора должнбг вБ13Б1ватБ аналогичнБге 
функцгш в базовом классе. В следугогцем разделе м i>i поговорим о том, как пра- 
вилбно определитБ тип ISerializable, базовБш тип которого не реализует даннБш 
интерфеис. 
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Если ваш производнми тип не имеет дополнителБнмх полеи и, следователћно, 
не нуждаетсн в oco6bix сериализации и десериализации, реализовБшатБ интерфеис 
ISenializable не нужно. Метод GetObjectData, как и все членБ 1 интерфеиса, нв- 
лиетси виртуалБНБш и вБИБшаетсл длл корректнои сериализации обвекта. Кроме 
того, модулБ форматировании считает специалвнБП! конструктор «виртуализиро- 
ванБш». То естБ во времл десериализации модулв форматировании провернет тип, 
зкземплнр которого он п 1 ,п аетси создатв. При отсутствии у зтого типа специалвного 
конструктора модулк форматировангш начинает сканироватв базовБге классБг, пока 
не наидет класс, в котором реализован нужнвш ему конструктор. 

ВНИМАНИЕ 

Код специалБного конструктора о6бнно извлекает полл из переданного ему обвекта 
Serializationlnfo. Однако извлечение полеи не гарантирует полнои десериализации 
обвекта, позтому код специалБного конструктора не должен модифицироватБ о6ђ- 
ектБ1, KOTopbie он извлекает. 

Если вашему типу нужен доступ к членам извлеченного обвекта (например, вмзов 
методов), следует снабдиљ тип методом с атрибутом OnDeserialized или заставити 
реализовмватБ MeTOflOnDeserialization интерфеиса IDeserializationCallback (какпока- 
зано в примере Dictionary). Вмзов зтого методазадаетзначенич полеи всех обЂектов. 
Но порлдок вмзова методов OnDeserialized и OnDeserialization длл набора обЂектов 
заранее не известен. Так что, несмотрп на инициализацик) полеи, если обЂект, на 
которми Bbi ccbmaeTecb, снабжен методом OnDeserialized или реализует интерфеис 
IDeserializationCallback, нелизл бмтнуверенни 1 м в его полнои десериализации. 


Определение типа, реализукпцего интерфеис 
ISerializable, не реализуемми базовмм классом 

Как уже упоминалосБ, интерфеис ISenializable нвлнетсн краине могцнбш инстру- 
ментом, позволнгогцим типу полностбго управлнтБ сериализациеи и десериализациеи 
своих зкземплиров. Однако за зту могцб приходитсн платитн ответственностБго 
типа за сериализацшо егце и всех полеи базового типа. Если базоввпг тип реализует 
также интерфеис ISenializable, нет никаких проблем — достаточно внгзватБ метод 
GetObjectData базового типа. 

Однако иногда требуетси определитв тип, управлнгогции сериализациеи, при 
условии, что его базоввш тип не реализует интерфеис ISenializable. В зтом случае 
производнБпг класс должен вручнуго сериализоватв поли базового типа, добавив 
их значенгш в коллекциго Senializationlnf о. Затем в специалвном конструкторе 
нужно будет извлечБ зтгг значенгш и задатн полн базового класса. В случае когда 
полн базового класса помеченвг модифггкатором public гглгг pnotected, зто не- 
сложно, а вот дла закрвгтвгх полеи задача может статн даже вообгце неразрешимогг. 

Следугогцгш код показвгвает, как правилвно реализоватБ метод GetObjectData 
интерфеиса ISenializable гг его конструктор, обеспечггвагогцгги серггалггзацггго 
полеи базового типа: 


Управление сериализованнв 1 ми и десериализованнмми данннми 685 


[Serializable] 
internal class Base { 

protected String m_name = "Jeff"; 

public Base() { /* Наделлем тип способноствн) создаватв зкземпллрн */ } 

} 

[Serializable] 

internal class Derived : Base, ISerializable { 
private DateTime m_date = DateTime.Now; 

public Derived() { /* Наделлем тип способноствга создавати зкземпллрн */ } 

// Если конструктор не суцествует, вмдаетсл SerializationException . 

// Если класс не запечатан, конструктор должен бмти зашишеннмм. 
[SecurityPermissionAttribute( 

SecurityAction.Demand, SerializationFormatter = true)] 
private Derived(SerializationInfo info, StreamingContext context) { 

// Получение набора сериализуеммх членов длл нашего и базовнх классов 
Туре baseType = this.GetType().BaseType; 

MemberInfo[] mi = FormatterServices.GetSerializableMembers( 
baseType, context); 

// Десериализацил полеи базового класса из обиекта даннмх 
for (Int32 i = 0; i < mi.Lengthj i++) { 

// Получение полл и присвоение ему десериализованного значенил 
Fieldlnfo fi = (FieldInfo)mi[i]j 
fi . SetValue(this, info.GetValue( 

baseType.FullName + "+" + fi.Name, fi.FieldType)); 

} 

// Десериализацин значении, сериализованншх длл зтого класса 
m_date = info.GetDateTime("Date")j 

} 

[SecurityPermissionAttribute( 

SecurityAction.Demand, SerializationFormatter = true)] 
public virtual void GetObjectData( 

Serializationlnfo info, StreamingContext context) { 

// Сериализацил нужнмх значении длл зтого класса 
info.AddValue("Date", m_date); 

// Получение набора сериализуеммх членов длл нашего и базовшх классов 
Туре baseType = this.GetType().BaseTypej 

MemberInfo[] mi = FormatterServices.GetSerializableMembers( 
baseType, context); 

// Сериализацин полеи базового класса в обцект данншх 
for (Int32 i = 0; i < mi.Lengthj i++) { 

// Полное имн базового типа ставим в префикс имени полн 
info.AddValue(baseType . FullName + "+" + mi[i].Name, 

((Fieldlnfo)mifi]).GetValue(this))j 

} 

} 
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public ovenride String ToStringO { 

return String.Format("Name={0}j Date={l}"j m_name, m_date); 

} 

} 

B зтом коде присутствует базовши класс Base, помеченнши толбко настра- 
иваемшм атрибутом SerializableAttnibute. Производнв 1 м от него лвлиетсл 
класс Derived, также помеченнши зтим атрибутом и реализукчции интерфеис 
ISerializable. Ситуацшо усугублнет тот факт, что оба класса определнгот поле типа 
String с именем m_name. При вшзове метода AddValue класса Serializationlnfo 
нелБЗи добавлитБ значентш с одним и тем же именем. Зто ограничение обходитсн 
путем присвоенгш каждому полго нового имени с префиксом из имени класса. К 
примеру, когда метод GetObjectData вшзшвает метод AddValue длл сериализации 
поли m_name класса Base, имн значенгш записшваетсл в форме ”Base+m_name". 


Контекстн потока ввода-внвода 

Как уже упоминалосв, сериализоватБ обвект можно куда угодно: в тот же самши 
процесс, в другои процесс на зтои же машине, в другои процесс на другои машине 
и т. п. Бшвагот ситуации, когда обвект нужно заранее уведомитБ, куда он будет де- 
сериализован, так как зто влгшет на его состонние. Например, обвект, нвлнгогцииси 
оболочкои дли Windows-ceMa^opa, может инициироватБ сериализациго дескрип- 
тора идра при условии, что десериализацин произоидет в том же процессе — ведв 
дескрипторБг лдра деиствителБНБг толбко в пределах одного процесса. При зтом 
если десериализацгш будет произведена в другои процесс на зтои же машине, 
обвект сможет сериализоватБ строковое имн семафора. Если же вдруг окажетсл, 
что десериализацгш ожидаетсл на другуго машину понвитсл исклгочение, так как 
семафорвг деиствителБНБг толбко в пределах однои машинБг. 

Рнд упомннутБгх в даннои главе методов в качестве параметра принимагот струк- 
туру StreamingContext. Зто простан структура значимого типа, имегогцан всего два 
открвгтБгх, предназначеннБгх толбко длн чтенгш своиства (табл. 24.1). 


Таблица 24.1 . Своиства перечисленич StreamingContext 


Имл 

члена 

Тип члена 

Описание 

State 

StreamingContextStates 

Набор битовнх флагов, указБшакнцих источник 
или приемник сериализуемБгх/десериализуемвгх 
даннћгх 

Context 

Object 

Ссмлка на обЂект, содержаш,ии нужнми полБЗОва- 
телш контекст 
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Получившии структуру StreamingContext метод может исследоватБ битовме 
флаги своиства State и определитБ источник или приемник сериализуемБ 1 х/десе- 
риализуемБ 1 х обвектов. Возможнвге значенгш флагов перечисленв! в табл. 24.2. 


Таблица 24.2. Флаги перечислениа StreamingContextStates 


Имч флага 

Значение 

флага 

Описание 

CrossProcess 

0x0001 

Источником или приемником лвллетсл другои про- 
цесс на тои же машине 

CrossMachines 

0x0002 

Источник или приемник находитсл на другои машине 

File 

0x0004 

Источником или приемником лвллетсн фаил. При 
зтом не стоит предполагатв, что десериализоватБ дан- 
HBie будет тот же самБхи процесс 

Persistence 

0x0008 

Источником или приемником лвллетсл хранилшце — 
такое, как база даннвгх или фаил. При зтом не стоит 
предполагатБ, что даннБге будут десериализоватБсл 
тем же процессом 

Remoting 

0x0010 

Взаимодеиствие с источником или приемником осу- 
ш,ествллетсл через механизм удаленного доступа. Они 
могут находитБСл как на тои же самои, так и на другои 

машине 

Other 

0x0020 

Источник или приемник неизвестнБ1 

Clone 

0x0040 

Точное копирование графа обвекта. Код сериализа- 
ции может предполагатв, что десериализацил даннБ 1 х 
будет вБшолнлтБсл тем же процессом, а значит, об- 
рагцение к дескрипторам и другим неуправлнемБШ 
ресурсам будет безопаснБхм 

CrossAppDomain 

0x0080 

Источником или приемником лвллетсл другои домен 
приложении 

All 

0x00FF 

Возможна передача или получение сериализованнБгх 
даннБ1Х из лк»6б1х упомннутБхх контекстов. Исполвзу- 
етсн по умолчаниго 


Теперв, когда вбг знаете, как получитк информацшо, поговорим о том, как ее 
задатв. В интерфеисе IFormatter (реализуемом как типом BinaryFormatter, так 
и типом SoapFormatter) определено доступное длн чтенгш и записи своиство типа 
StreamingContext с именем Context. В процессе конструировангш модулв форма- 
тированин инициализирует своиство Context, присваиван StreamingContextStates 
значение All, а ссвшке на дополнителБНБш обвект состоингш — значение null. 
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После создании модулн форматированин можно создатБ структуру Streaming- 
Context, исполБзул лгобме битовме флаги StreamingContextStates, с возмож- 
ностбго передачи ссмлки на обвект, содержагции дополнителБнуго контекстнуго 
информациго. После чего остаетсл присвоитБ своиству Context новми обвект 
StreamingContext до вмзова метода Serialize или Deserialize. Показаннми 
ранее метод DeepClone демонстрирует, как сообгцитБ модулго форматировангш, 
что сериализацил/десериализацин графа обвектов вмполннетсл исклгочителвно 
с целБГО клонировангш всех обЂектов. 


Сериализацил в другои тип 
и десериализацил в другои обт>ект 

Инфраструктура сериализации в .NET Framework обладает достаточно широкими 
возможностнми. В частности, она позволнет разработчикам создаватБ типм, до- 
пускагогцие сериализациго и десериализациго в другои тип или обвект. НесколБКО 
примеров ситуации, в котормх зто может 6 мтб нужно: 

□ Некоторме типм (например, System.DBNull и System.Reflection.Missing) 
допускагот сугцествование в домене приложении толвко одного зкземплира. 
Их часто назмвагот однозлементними (singleton). Если у вас имеетсл ссмлка 
на DBNull, ее сериализации и десериализацгш не приведет к созданиго в домене 
нового обЂекта. Возврагцаеман после десериализации ссмлка должна указмватЂ 
на уже сугцествугогции в домене обвект DBNull. 

□ Некоторме типм (например, System . Туре, System . Ref lection . Assembly и другие 
свизаннме с отраженинми тггпм, такгге как Memberlnf о) допускагот сугцествование 
всего одного зкземплира на тип, сборку, член и т. п. ПредставЂте массггв ссмлок 
на обЂектм Memberlnfo. Допустима ситуацгш, когда пнтб ссђглок указмвагот на 
один обвект. Зто состонние должно сохранитЂСи и после сериализации и десе- 
риализации. Более того, злементм должнм ссмлатЂСн на обвект Memberlnfo, 
сугцествугогции в домене длн определенного члена. Такои подход полезен также 
дли последователвного опроса обвектов подклгоченин к базе даннмх и лгобмх 
других типов обвектов. 

□ Длн обвектов, контролируеммх удаленно, CLR сериализует информациго о сер- 
верном обвекте таким образом, что при десериализации на клиенте CLR создает 
обвект, нвлнгогцииси представителем (ргоху) сервера на стороне клиента. Тип 
представителн отличаетсл от типа серверного обвекта, но дли клиентского кода 
зта ситуацин прозрачна. Если клиент вмзмвает д./г л обЂекта-представителл зк- 
земплнрнме методн, код представителн переправлнет вмзов на сервер, которми 
в деиствителЂности и обрабатмвает запрос. 

Следугогции пример демонстрирует корректное вмполнение серггализации 
и десериализации однозлементного типа: 
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// Разрешен толвко один зкземпллр типа на домен 
[Serializable] 

public sealed class Singleton : ISerializable { 

// Единственнши зкземпллр зтого типа 

private static readonly Singleton theOneObject = new Singleton(); 

// Полл зкземпллра 

public String Name = "Deff"; 

public DateTime Date = DateTime.Now; 

// Закрштми конструктор длл созданил однокомпонентного типа 
private Singleton() { } 

// МетодЈ возврацакпции ссшлку на однозлементнми тип 

public static Singleton GetSingleton() { return theOneObject; } 

// МетодЈ вшзмваемми при сериализации обЂекта Singleton 

// Рекомендук) исполвзоватц ввнук) реализацик) интерфеисного метода. 

[SecurityPermissionAttribute( 

SecurityAction.Demandj SerializationFormatter = true)] 
void ISerializable.GetObjectData( 

Serializationlnfo info, StreamingContext context) { 
info.SetType(typeof(SingletonSerializationHelper)); 

// Добавлвтц другие значенил не нужно 

} 

[Serializable] 

private sealed class SingletonSerializationHelper : IObjectReference { 
// Метод, Bbi3biBaeMbin после десериализации зтого обЂекта (без полеи) 
public Object GetRealObject(StreamingContext context) { 
return Singleton.GetSingleton(); 

} 

} 

// ПРИМЕЧАНИЕ . Специал 1 =нми конструктор HE НУЖЕНј 
// потому что он нигде не вћвшваетсв 

} 


Класс Singleton представлиет тип, дли которого в домене приложении может 
сугцествоватБ to.ti.ko один зкземплир. Показаннми далее код тестирует процеду- 
рм сериализации и десериализации зтого типа, обеспечиван вмполнение данного 
условгш: 

private static void SingletonSerializationTest( ) { 

// Создание массива с несколцкими ссмлками на один обцект Singleton 
Singleton[] al = { Singleton.GetSingleton( ), Singleton.GetSingleton() }; 
Console.WriteLine("Do both elements refer to the same object? " 

+ (al[0] == al[l])); // "True" 

using (var stream = new MemoryStream()) { 

BinaryFormatter formatter = new BinaryFormatter(); 

// Сериализацив и десериализацил злементов массива 

продолжение & 
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formatter.SerializeCstream, al); 

stream.Position = 0; 

Singleton[] a2 = (Singleton[])formatter.Deserialize(stream); 

// Проверлем, что все работает, как нужно: 

Console.WriteLine("Do both elements refer to the same object? " 

+ (a2[0] == a2[l])); // "True" 

Console.WriteLine("Do all elements refer to the same object? " 

+ (al[0] == a2[0])); // "True" 

} 

} 

Попштаемсл понптб, что же происходит. Длл загруженного в домен типа 
Singleton CLR вмзмвает статическии конструктор, создаклции обвект Singleton 
и сохраннкшцш ссмлку на него в статическом поле s_theOneObject. Класс Singleton 
не имеет открмтмх конструкторов, что не дает стороннему коду создаватБ его зк- 
земплнрБт 

В методе SingletonSerializationTest создаетсл массив из двух злементов, 
каждћш из которБ 1 х ссБ 1 лаетсл на обвект Singleton. Длл инициализации зтих оле- 
ментов вБ13Б1ваетсл статическии метод GetSingleton класса Singleton. Он возвра- 
гцает ссБшку на один обвект Singleton. ПервБП! вбвов метода WriteLine вбшодит 
"Т rue", указБшаи, что оба злемента массива ссБшаготси на один обвект. 

Далее метод SingletonSerializationTest вБ13Бшает метод Serialize мо- 
дулн форматировании длл сериализации массива и его злементов. Обнаружив, 
что тип Singleton реализует интерфеис ISerializable, модулв форматиро- 
ванил вБ13Б1вает метод GetObjectData, которвш передает в метод SetType тип 
SingletonSerializationHelper. В резулвтате модулБ форматированин сериализует 
обвект Singleton в качестве обвекта SingletonSerializationHelper. Так как метод 
AddValue в данном случае не вввБшаетсл, в поток ввода-ввшода не записБшаетсл 
никакои дополнителБнои информации. Кроме того, модулн форматированин, обна- 
ружив, что оба злемента массива ссвшаготси на один и тот же обвект, сериализует 
ТОЛБКО один из них. 

После сериализации массива метод SingletonSerializationTest ввгоБшает метод 
Deserialize модули форматировангш. При работе с потоком ввода-ввшода модулБ 
форматировашш пБ 1 таетсл десериализоватБ обвект SingletonSerializationHelper, 
которБП! с его точки зренгш 6 б 1 л им ранее сериализован (на самом деле, именно 
позтому класс Singleton не имеет специалБного конструктора, о 6 б 1 чно тре- 
бугогцего реализации интерфеиса ISerializable). Сконструировав обвект 
SingletonSerializationHelper, модулв форматировашш обнаруживает, что дан- 
нбш тип реализует интерфеис System . Runtime . Serialization . 10b jectRef erence. 
B FCL зтот интерфеис определиетсл следугошим образом: 

public interface IObjectReference { 

Object GetRealObject(StreamingContext context); 

} 
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Длн реализуклцих такои интерфеис типов модулБ форматированин вмзмвает 
метод GetRealOb ject, возврашаговдии ссмлку на обвект, на которми вм деиствителБ- 
но хотите сослатћсн после завершенин десериализации. В моем примере д./г л типа 
SingletonSenializationHelpen метод GetRealObject возврашает ссвшку на уже 
сутцествуготции в домене обвект Singleton. После возвранденин управленин методом 
Desenialize массив а2 содержит два злемента, каждБ1и из которБ1х ссБшаетсн на 
обвект Singleton домена. ВспомогателБНБш обвект SingletonSenializationHelpen, 
исполБЗОвавшиисн при десериализации, в дашњш момент недоступен и будет 
уничтожен при следугогцеи сборке мусора. 

Второи вБгзов метода WniteLine вбшодит значение "Tnue ", подтверждал, что оба 
злемента массива а2 указвшагот на один и тот же обвект. АналогичнБпг резулБтат 
дает третии и последнии вбгзов зтого метода, так как на один и тот же обвект и в 
самом деле указвшагот злементБ! обоих массивов. 


Суррогатн сериализации 

До зтого момента mbi обсуждали спосо 6 б 1 измененин реализации типов, позволнго- 
гцие управлитБ сериализациеи и десериализациеи их зкземшшров. Однако сугце- 
ствует возможностб переопределитБ поведение зтих процессов при помогци кода, 
не принадлежагцего реализации типа. Длн чего зто может 6 bitb нужно? 

□ Разработчик может сериализоватБ типбт, длл которБ 1 х возможностб сериализацгш 
не 6 бшц учтена при исходном проектировангш. 

□ Возможностб отображенгш между разнБши версгшми одного типа. 

4to6bi зтот механизм заработал, нужно определитБ «суррогатнБпг тип», которБпг 
возБмет на себи работу по сериализации и десериализации сугцествугогцего типа. 
Затем следует зарегистрироватБ зкземплнр суррогатного типа, сообгцив модулго 
форматировангш, за деиствгш какого сугцествугогцего типа он будет отвечатв. В ре- 
зулкгате при попБ1тке сериализоватБ или десериализоватБ зкземплнр сугцествугогцего 
типа модулБ форматировангш будет вБгзвшатБ методБ1, определеннБге суррогатнБш 
обвектом. Следугогции пример показкшает, как все зто работает. 

Тип суррогата сериализацгш должен реализоввшатБ интерфеис System . Runtime . 
Senialization . ISenializationSunnogate, определнемБш в FCL следугогцим об- 
разом: 

public interface ISerializationSurrogate { 

void GetObjectData(Object obj, Serializationlnfo info, 

StreamingContext context); 

Object SetObjectData(Object obj, Serializationlnfo info, 

StreamingContext context, ISurrogateSelector selector); 

} 
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Теперц посмотрим на пример исполћзовании зтого интерфеиса. Предположим, 
программа содержит о6ђсктм DateT ime, значенин котормх привнзанм к компћготеру 
полБЗОватели. Каким образом сериализоватћ зти обвектм в поток ввода-вмвода, 
указав их значенгш, как всемирное времн? ВедБ толбко при таком подходе вб1 мо- 
жете перенаправитБ поток на машину, расположеннуго на другом конце планетБц 
сохранив корректнБ1е значенгш датБ 1 и времени. Так как Bbi не можете меннтБ тип 
DateTime, представленнБ 1 и в FCL, остаетсл определитБ собственнБи! суррогатнБП! 
класс, управлигогции сериализациеи и десериализациеи обвектов DateTime. Вот 
как он вБ1гллдит: 

internal sealed class UniversalToLocalTimeSerializationSurrogate : 
ISerializationSurrogate { 

public void GetObjectData( 

Object obj, Serializationlnfo info, StreamingContext context) { 

// Переход от локалБного к мировому времени 

info.AddValue("Date" , ( (DateTime)obj ). ToUniversalTime().ToString("u")); 

} 

public Object SetObjectData(Object obj, Serializationlnfo info, 

StreamingContext context, ISurrogateSelector selector) { 

// Переход от мирового времени к локалБному 
return DateTime . ParseExact( 

info.GetStringC'Date"), "u", null).ToLocalTime(); 

} 

} 

Здссб метод GetObjectData работает почти как одноименнБпг метод интерфеиса 
ISerializable. Отличаетсн он всего одним параметром: ссбшкои на <<реалБНБпг>> о6ђ- 
ект, которБпг требуетсл сериализоватБ. В показанном варианте метода GetOb ј ectData 
даннБпг обвект приводитсн к типу DateTime, его значение преобразуетсн из локалБ- 
ного в универсалБное времи, а полученнан в итоге строка (отформатированнан 
с исполБЗОванием универсалБного шаблона полнои датБг/времени) добавлнетсл 
в коллекциго Serializationlnfo. 

Длн десериализации обвекта DateTime вБгзБшаетси метод SetObjectData. Ему 
передаетсл ссБшка на обЂект Serializationlnfo. Метод извлекает из коллекции 
строковБ1е даннБ1е, разбирает их как строку в формате универсалБнои полнои 
датБг/времени и преобразует полученнБпг обвект DateTime в формат локалБного 
машинного времени. 

ПервБпг параметр метода SetOb jectData, обвект Ob ject, вбшллдит немного стран- 
но. Непосредственно перед вбгзовом метода модулБ форматировангш вБвделлет место 
(через статическии метод GetUninitializedObject класса FormatterServices) под 
зкземплнр типа, длн которого предназначаетсн суррогат. Все полн зтого зкземплнра 
имегот значение 0 или null, и длл обЂекта не вБИБшаетсл никаких конструкторов. 
Метод SetObjectData может просто инициализироватБ его полн, исполБзун значенгш 
из переданного методу обвекта Serializationlnfo, а затем вернутБ значение null. 
В качестве алБтернативБ! метод SetObjectData может создатБ совсем другои обвект 
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или даже другои обЂектнми тип и вернутЂ ссмлку на него. В зтом случае модулЂ 
форматированин проигнорирует лгобме измененгш, которме могли произоити 
с оођсктом, переданнмм им в метод SetObjectData. 

В моем npiiMepeK^accUniversalToLocalTimeSerializationSurrogate деиствует 
как суррогат длл значимого типа DateTime. И позтому параметр obj ссмлаетсл на 
упакованнми зкземплир типа DateTime. МеннтЂ поли в болЂшинстве значиммх 
типов нелБЗи (так как они предполагаготсл неизменнмми), позтому мои метод 
SetObjectData игнорирует параметр obj и возврашает новми обвект DateTime 
с нужнмм значением. 

Как же при сериализации/десериализации обвекта DateT ime модулБ форматиро- 
ванин узнает о необходимости исполБЗОвашга типа ISerializationSurrogate? Сле- 
дукнции код тестирует класс UniversalToLocalTimeSerializationSurrogate: 

private static void SerializationSurrogateDemo() { 
using (var stream = new MemoryStream()) { 

// 1. Создание желаемого модулл форматированил 
IFormatter formatter = new SoapFormatter(); 

// 2. Создание обБекта SurrogateSelector 
SurrogateSelector ss = new SurrogateSelector(); 

// 3. Селектор втбирает наш суррогат длл обБекта DateTime 
ss . AddSurrogate(typeof(DateTime)j formatter.Context, 
new UniversalToLocalTimeSerializationSurrogate()); 

// ПРИМЕЧАНИЕ. AddSurrogate можно вшзмватв более одного раза 
// длл регистрации несколцких суррогатов 

// 4. Модулц форматированил исполцзует наш селектор 
formatter.SurrogateSelector = ss; 

// Создание обцекта DateTime с локалцншм временем машинш 
// и его сериализацил 

DateTime localTimeBeforeSerialize = DateTime.Now; 
formatter. Serialize(strearru localTimeBeforeSerialize); 

// Поток вмводит универсалцное времл в виде строки, 

// проверлл, что все работает 
stream.Position = @; 

Console.WriteLine(new StreamReader(stream) . ReadToEnd( ) ); 

// Десериализацил универсалцного времени и преобразование 
// обцекта DateTime в локалцное времл 
stream.Position = @; 

DateTime localTimeAfterDeserialize = 

(DateTime)formatter.Deserialize(stream) ; 

// Проверка корректности работш 
Console.WriteLine( 

"LocalTimeBeforeSerialize ={0}"j localTimeBeforeSerialize); 


продолжение & 
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Console.WriteLine( 

"LocalTimeAfterDeserialize={0}", localTimeAfterDeserialize) ; 

} 

} 

После виполнении четвертого шага модулБ форматированин готов к работе 
с суррогатнБши типами. При вБ130ве метода Senialize тип каждого обвекта игцетсн 
в наборе, поддерживаемом обвектом SurrogateSelecton. При обнаружении соот- 
ветствин вБ13Бшаетсн метод GetOb jectData класса ISerializationSurrogate, что 6 б 1 
получитБ информацшо длл записи в поток ввода-ввшода. 

При вБ130ве метода Deserialize тип подлежагцего десериализации обвекта 
также игцетси в обвекте SurrogateSelector, и при обнаружении соответствии bbi- 
ЗБшаетсн метод SetObjectData класса ISerializationSurrogate, задагошии поли 
десериализуемого обвекта. 

Обвект SurrogateSelector управлпет закрвгтои хеш-таблицеи. При вб 1 .зо- 
ве метода AddSurrogate значенил Туре и StreamingContext формиругот клгоч, 
а обвект ISerializationSurrogate исполвзуетсн как значение. Если клгоч длл 
рассматриваемои комбинации Type/StreamingContext уже сугцествует, метод 
AddSurrogate генерирует исклгочение ArgumentException. Присутствие в клгоче 
обвекта StreamingContext позволнет зарегистрироватв два обвекта суррогатного 
типа: один умеет сериализоватв в фаил обвект DateT ime, второи — сериализоватв/ 
десериализоватв обвект DateTime в другои процесс. 

ПРИМЕЧАНИЕ 

В классе BinaryFormatter суидествует ошибка, из-за которои суррогат не может 
сериализоватБ ссБтаклциесл друг на друга обвек™. Длл ее устраненил следует 
передатБ ссмлку на обвект ISerializationSurrogate статическому методу GetSurrog 
ateForCyclicalReference класса FormatterServices. Зтот метод возврагдает обЂект 
ISerializationSurrogate, которБ 1 и затем можно передатБ методу AddSurrogate класса 
SurrogateSelector. Однако при работе с методом GetSurrogateForCyclicalReference 
метод SetObjectData вашего суррогата должен менлтБ значение внутри обвекта, 
на которни ссБшаетсл параметр obj, и в конце концов возвраидатБ вБ13Б1вакдидему 
методу значение null или obj. В прилагаемом к книге коде (он доступен длл за- 
грузки) демонстрируетсл, как отредактироватБ класс UniversalToLocalTimeSeriali 
zationSurrogate и метод SerializationSurrogateDemo, чтобБ 1 обеспечитБ поддержку 
циклических ссмлок. 


Цепочка селекторов суррогатов 

НесколБКО обвектов SurrogateSelector можно свнзатв в цепочку. К примеру, у вас 
может 6 б 1 тб обвект SurrogateSelector с набором суррогатов сериализации, пред- 
назначеннБгх дли сериализации типов в представители с целвго передачи по каналу 
свнзи или между доменами приложении. Может сугцествоватв и специалБНБш о 6 б- 
ект SurrogateSelector с набором суррогатов сериализации, предназначеннБгх длн 
преобразовании типов версии 1 в типбг версии 2 . 
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Чтобм модулв форматированин смог исполБЗОватг. все зти o6teKTbi, их нужно сое- 
динитб в цепочку. Тип SurrogateSelector реализует интерфеис ISurrogateSelector, 
определнгогции три метода. Все они свнзанБ 1 с созданием цепочек. Вот определение 
интерфеиса ISurrogateSelector: 

public interface ISurrogateSelector { 

void ChainSelector(ISurrogateSelector selector); 

ISurrogateSelector GetNextSelector(); 

ISerializationSurrogate GetSurrogate( 

Туре type, StreamingContext context, out ISurrogateSelector selector); 

} 

Метод ChainSelector вставлнет обвект ISurrogateSelector после того о6ђ- 
екта ISurrogateSelector, с которћш ведетсл работа (на него указћшает клгочевое 
слово this). Метод GetNextSelector возврагцает ссБшку на следугогции обвект 
ISurrogateSelector в цепочке, или значение null, если цепочка закончиласБ. 

Метод GetSurrogate шцет пару Type/StreamingContext в обвекте ISurrogate- 
Selector, идентифицируемом клгочевБш словом this. Если пара не обнаруживаетси, 
рассматриваетси следугогции обвект ISurrogateSelector и т. д. В случае же обна- 
руженил napbi метод GetSurrogate возврашает обвект ISerializationSurrogate, 
вбшолнлгогции сериализациго/десериализациго просматриваемого типа. Кроме того, 
возврашаетсл содержагции пару обвект ISurrogateSelector; но необходимости 
в зтом обБшно нет, и даннми резулкгат работм метода игнорируетсн. Если ни один 
из обЂектов ISurrogateSelector в цепочке не имеет совпадении дли парм Туре/ 
StreamingContext, метод GetSurrogate возврагцает значение null. 

ПРИМЕЧАНИЕ 

В FCL определен интерфеис ISurrogateSelector и реализукнции его тип Surroga- 
teSelector. При зтом практически никто и никогда не определлетсобственнБ 1 хтипов, 
реализукндих зтот интерфеис. ВедБ единственнои причинои его созданил может 
6biTb разве что повишеннал гибкости при отображении между типами — например, 
если возникает необходимосљ сериализоватв все Tnnbi, наследукзидие от опреде- 
ленного базового класса определеннмм образом. Превосходнмм образчиком такого 
класса лвллетсл System.Runtime.Remoting.Messaging.RemotingSurrogateSelector. 
Сериализул o6teKTbi длл удаленнои передачи, CLR форматирует их методом 
RemotingSurrogateSelector. Зтот суррогатнми селектор сериализует все производнме 
OTSystem.MarshalByRefObjecto6beKTbiTaKHM образом, что десериализацил приводит 
к созданикз обвектов-представителеи на стороне кпиента. 


Переопределение сборки и/или типа 
при десериализации обг»екта 


В процессе сериализации обвекта модули форматировашга вмводит в поток полное 
ими типа и полное ими определигогцеи зтот тип сборки. При десериализации зта 
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информации позволнет им точно узнатБ тип конструируемого и инициализируе- 
мого обЂекта. При обсуждении интерфеиса ISerializationSurrogate н продемон- 
стрировал механизм, позволнгогции производитБ сериализациго и десериализацшо 
определенного типа. Тип, реализугогции интерфеис ISerializationSurrogate, 
привнзан к определенному типу в определеннои сборке. 

Однако бвгвагот ситуации, когда указаннвпг механизм оказБшаетсн недостаточно 
гибким. Вот ситуации, в которвгх может оказатБСн полезнБгм десериализацгш о6б- 
екта в другои тип: 

□ Перемегцение реализации типа из однои сборки в другуго. Например, номер 
версии сборки мениетсн, и нован сборка начинает отличатвси от исходнои. 

□ Обвект с сервера сериализуетсл в поток, отправлнемвги на сторону клиента. При 
обработке потока клиент может десериализоватБ обвект в совершенно другои 
тип, код которого «знает», как удаленнвш методом обратитБСл к обвектам на 
сервере. 

□ Разработчик создает новуго версиго типа и именно в нее требуетсн десериали- 
зоватБ все ранее сериализованнвге обвектБг. 

Десериализацгш обвектов в другои тип легко ввшолниетсл при помогци класса 
System . Runtime . Serialization . SerializationBinder. Достаточно определитБ 
тип, производнБш от абстрактного типа SerializationBinder. В показанном далее 
коде предполагаетсл, что версгш 1.0.0.0 сборки определлет класс с именем Verl. 
И зта новаи версин определлет класс VerlToVer2SerializationBinder и класс 
с именем Ver2: 

internal sealed class VerlToVer2SerializationBinder : SerializationBinder { 
public override Туре BindToType(String assemblyName, String typeName) { 

// Десериализацип обБекта Verl из версии 1.0.0.0 в обБект Ver2 

// Вћписление имени сборки, определвкицеи тип Verl 

AssemblyName assemVerl = Assembly.GetExecutingAssembly().GetName(); 

assemVerl.Version = new Version(l, 0, 0, 0); 

// При десериализации обБекта Verl версии vl.0.0.0 преврашаем его в Ver2 
if (assemblyName == assemVerl.ToString() && typeName == "Verl") 
return typeof(Ver2); 

// B противном случае возврацаем запрошеннши тип 

return Type.GetType(String.Format( "{0}, {1}", typeName, assemblyName)); 

} 

} 

После создангш модулн форматированин нужно создатБ зкземплир Venl- 
ToVen2SenializationBinden и присвоитБ открБгтому длн чтенгш и записи своиству 
Binden ссБглку на обвект привнзки. После зтого можно вБкшватБ метод Desenialize. 
В процессе десериализации модулн форматировангш обнаружит привнзку и длн 
каждого обрабатвшаемого обвекта вкгзовет метод BindToType, передаван ему имн 
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сборкии тип, которме требуетси десериализоватћ. Назтои стадии метод BindToType 
решает, какои тип следует сконструироватћ, и возврапдает зтот тип. 

ПРИМЕЧАНИЕ 

Класс SerializationBinder позволлет также в процессе сериализации менлтв инфор- 
мацикз о сборке/типе путем переопределенил метода BindToName. Даннвш метод 
внгллдит следукдцим образом: 

public virtual void BindToName(Type serializedType, 
out string assemblyName, out string typeName) 

Bo времл сериализации модулв форматированил Bbi3bieaeT даннми метод, пере- 
давал тип, которми он собираетсл сериализоватв. После зтого bw можете передати 
(при помоиди двух параметров out) сборку и тип, KOTopbie хотите сериализовате вм. 
Если же в параметрах передакзтсл null и null (именно ето происходит в заданнои по 
умолчаникз реализации), тип и сборка остакзтсл без изменении. 


Глава 25. Взаимодеиствие 
с компонентами WinRT 


В Windows 8 понвиласћ нован библиотека классов, при помотци которои приложе- 
нии могут исполБЗОватБ функционалБностБ операционнои системБ1. Зта библио- 
тека классов официалБно назћшаетси Windows Rimtime (WinRT), а длл работБ 1 с ее 
компонентами применнетси система типов WinRT. Многие задачи, длл решенин 
котормх создаваласв WinRT, совпадагот с задачами обгцеизвшовои средм CLR в ее 
исходном воплогцении — например, упрогцение разработки приложенгш и про- 
стое взаимодеиствие с кодом, написаннмм на других извгках программировангш. 
Компангш Microsoft обеспечивает поддержку исполвзовангш компонентов WinRT 
в неуправлнемом коде С/С++, в JavaScript (длл виртуалвнои машинБг JavaScript 
«Chakra» от Microsoft), а также в C# и Visual Basic. 

На рис. 25.1 представленБг различнБге возможности, предоставлиемвге компо- 
нентами WinRT, и различнме нзмки, поддерживаемБге Microsoft длн работБг с ними. 
Код приложенгш, написаннБгх на неуправлнемом С/С++, должен компилироватБСл 
длн каждои конкретнои архитектурБг процессора (х86, х64 и ARM). Разработчикам 
Microsoft .NET Framework достаточно откомпилироватБ свои код в IL -код, чтобвг 
потом среда CLR преобразовала его в машиннБш код длл конкретного процессора. 
Разработчики JavaScript вклгочагот исходнбш код в свое приложение, а виртуалвнан 
машина «Chakra» разбирает его и преобразует в машиннБш код конкретного про- 
цессора. Другие компании тоже могут вншускатБ нзбгки и средкг, поддерживагогцие 
взаимодеиствие с компонентами WinRT. 

Приложенгш Windows Store и настолБнвге приложенгш могут исполБЗОватБ 
компонентБг WinRT длн обрагценгш к функционалБности операционнои системБг. 
Пока количество компонентов WinRT, поставлнемвгх как составнан частв Windows, 
относителБно невелико по сравнениго с размером библиотеки классов .NET 
Framework. Впрочем, зто вполне естественно, потому что компонентБг ориентиро- 
ванБг на решение тех задач, с которнши операционнаи система справлиетсл лучше 
всего: предоставленгш разработчикам абстрактного представленгш оборудовангш 
и средств взаимодеиствгш между приложешшми. Таким образом, болвшинство 
компонентов WinRT предоставлиет такие функцгш, как хранение информации, 
сетевме операцгш, графика, мулБтимедиа, безопасностБ, многопоточностб и т. д. 
Другие базовБге средства (например, операции со строками) и более сложнвге под- 
системБг (например, поддержка LiNQ) операционнои системои не поддерживаготси, 
а предоставлиготсл избгком, исполБзуемБгм дли работБг с компонентами WinRT 
операционнои системБг. 
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Рис. 25.1 . ФункционалБностБ компонентов WinRT и различнме лзи 1 ки, 
поддерживаемме Microsoft длп работм с ними 


Во внутреннеи реализации компонентм WinRT представлнкзт собои компо- 
нентн СОМ (Component Object Model) — технологии, представленнои компаниеи 
Microsoft в 1993 году. СОМ имеет репутациго излишне сложнои модели с множе- 
ством запутаннмх правил и краине громоздкои моделБК) программировании. Тем 
не менее в модели СОМ бмло заложено немало правилгшмх идеи, и за прошедшие 
годм разработчики Microsoft приложили значителгшме усилин по ее упрогценшо. 
Длн компонентов WinRT компанип Microsoft ввела оченБ зпачитс.њпое измененне: 
вместо библиотек типов длн описанин APl компонентов СОМ теперп исполБзуготсп 
метаданнме. Да, АРО компонентов WinRT описмваетсн в формате метаданнмх .NET 
(ЕСМА-335), которми бмл стандартизирован комитетом ЕСМА — и в том самом 
формате метаданнмх, которми рассматривалсп в зтои книге. 

Метаданнме обладагот зпачитслппо бо.тпшими возможностнми, чем библиотеки 
типов, аих полноценнап поддержка изпача.тппо заложена в CLR. Кроме того, CLR 
поддерживает взаимодеиствие с компонентами СОМ через обертки RCW (Runtime 
Callable Wrappers) и CCW (COM Callable Wrappers). B обшем и целом зто позво- 
лпет нзмкам (таким, как С#), работагогцим на базе CLR, легко взаимодеиствоватБ 
с типами и компонентами WinRT. 

В C# ссБшка на обпект WinRT в деиствителвности представлнет собои ссвшку 
на обертку RCW, котораи содержит внутреннгого ссвшку на обпект WinRT. Ана- 
логичнмм образом при передаче обпекта CLR WinRT APl вм в деиствителпности 
передаете ссншку на обертку CCW, а CCW содержит сскшку на обпект CLR. 

МетаданнБге компонентов WinRT храннтсп в фаилах с расширением .winmd. 
У компонентов WinRT, входнгцих в поставку Windows, метаданнме храннтсн в фаи- 
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лах Windows.*.winmd, находншихсн в каталоге %WinDir%\System32\WinMetadata. При 
построении приложенин исполБзуетси ссмлка на следугогции фаил Windows.winmd, 
устанавливаемми Windows SDK: 

%ProgramFiles(x86)%\Windows Kits\8.0\References\CommonConiguration\Neutral\Windows. 
winmd 

Система типов Windows Runtime создаваласв, прежде всего, длл того, чтобм 
разработчики могли успешно писатБ приложенин с применением всех знакомћгх им 
технологии, инструментов, приемов и соглашении. Длл зтого некоторвге функции 
WinRT проецировалисв на соответствугогцие технологии разработки. Длн разра- 
ботчиков .NET Framework сугцествует два вида проекции: 

□ Проекции уровнн CLR неивно реализуготси средои CLR (и как правило, в от- 
ношении интерпретации метаданнвгх). Следугогции раздел посвнгцен правилам 
системвг типов компонентов WinRT и тому, как CLR проецирует зти правила 
на парадигму разработки .NET Framework. 

□ Проекции уровни .NET Framework реализуготсл нвно в вашем коде посред- 
ством исполБЗОвашш новбгх API, введеннБгх в FCL. Проекции уровнп ,NET 
Framework необходимБг в тех ситуацгшх, когда рассогласование между системои 
типов WinRT и системои типов CLR становитсл слишком значителвнмм длн 
неивного разрешенгш средствами CLR. Проекции уровнн .NET Framework рас- 
сматриваготсн далее в зтои главе. 


Проекции уровнл CLR и правила систег/њ1 
типов компонентов WinRT 

Компонентвг WinRT образугот систему типов, сходнуго с системои типов CLR. Когда 
среда CLR встречает тип WinRT, она обмчно разрешает исполвзование зтого типа 
с исполБЗОванием обвгчнБгх технологии взаимодеиствгш CLR. Однако в некоторвгх 
случалх CLR скрвшает тип WinRT и предоставлнет доступ к нему через другои тип. 
Во внутреннеи реализации CLR игцет некоторме типм (при помогци метаданнмх), 
а затем отображает их на типм FCL. Полнми список типов WinRT, которме CLR 
неивно проецирует на типм FCL, доступен по адресу http://msdn.microsoft.com/ 
еп - us/library/windows/apps/hh995050.aspx. 

OcHOBHbie концепции системм типов WinRT 

Система типов WinRT по функционалвности уступает системе типов CLR. Ниже 
перечисленБг основнбш концепции системБг типов WinRT и способм их проекции CLR. 

Имена фаилов и пространства имен. Ими самого фаила .winmd должно со- 
впадатв с именем пространства имен, содержагцего компонентвг WinRT. Напри- 
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мер, фаил с именем Wintellect.WindowsStore.winmd должен содержатБ компонентБг 
WinRT, определеннБге в пространстве имен Wintellect .WindowsStore или в одном 
из его подпространств. ПосколБку фаиловаи система Windows не учитћгвает ре- 
гистр символов, пространства имен, различагогциесн толбко регистром символов, 
недопустимБт Кроме того, имн компонента WinRT не может совпадатБ с именем 
пространства имен. 

Обиции базовми тип. Компонентвг WinRT не имегот обшет базового класса. 
Когда CLR проецирует тип WinRT, все вмгллдит так, словно тип WinRT ивлнетси 
производнвш от System . 0b ject; соответственно все типбг WinRT наследугот такие 
открБггБгеметодБг, как ToStning, GetHashCode, Equals и GetType. При исполБЗОвании 
обвекта WinRT в C# обвект кажетсл производнмм от System.0bject, а обвектБ 1 
WinRT могут передаватБСи в коде. Также возможен вбгзов «унаследованнБ 1 х» ме- 
тодов — таких, как ToStning. 

Основнме типм даннмх. Система типов WinRT поддерживает основнме типм 
даннмх: логическии, баитовми без знака, 16-, 32 и 64-разриднме целме числа со 
знаком и без, вегцественнме числа одинарнои и двоинои точности, 16-разриднме 
символм, строки и void 1 . Все осталвнме типб 1 даннБ 1 Х, как и в CLR, образуготси из 

ЗТИХ ОСНОВНБ1Х ТИПОВ ДаННБ1Х. 

Классм. Система типов WinRT нвлнетсл обБектно-ориентированнои; зто озна- 
чает, что компонентвг WinRT поддерживагот абстракциго даннмх, наследование и 
полиморфизм 2 . Однако некоторвге измки (например, JavaScript) не поддерживагот 
наследование типов, и в интересах зтих измков компонентм WinRT почти не ис- 
полБзугот наследование, а зто значит, что они также не исполвзугот полиморфизм. 
По сути наследование и полиморфизм задеиствованБ 1 толбко теми компонентами 
WinRT, предназначеннмх длл других нзмков, помимо JavaScript. Из компонентов 
WinRT, вклгоченнмх в поставку Windows, наследование и полиморфизм исполвзу- 
готсн толбко компонентами XAML (длл построенгш полкзователБСКих интерфеисов). 
Приложенгш, написаннБге на JavaScript, стролт свои полБЗОвателвскгш интерфеис 
средствами HTML и CSS. 

Структурм. WinRT поддерживает структурм (значимме типм), зкземплирм 
которБ1х продвигаготсп по значениго через границБ1 взаимодеиствии (interoperability 
boundary) СОМ. В отличие от значиммх типов CLR, структурм WinRT могут 
содержатв толбко открБгтБге поли, которме относлтсл к основнмм типам даннмх 
(или нвлиготси другими структурами WinRT) 3 . Кроме того, структурм WinRT не 
могут определнтв конструкторБ 1 или вспомогателБНБге методБг. Дли удобства CLR 
проецирует некоторвге структурБ 1 операционнои системБ 1 WinRT на собственнме 
типм CLR, которме могут содержатв конструкторБ! и вспомогателБНБге методБ!. 


1 BaiiTOBbiii тип со знаком в WinRT не поддерживаетсл. 

2 Абстракцин даннБ 1 х обнчно поддерживаетсн принудителБно, посколвку классБ 1 WinRT 
не могут иметБ открБ1тБ1х полеи. 

3 Перечисленин тоже допустимБ1, посколБку они фактически лвллготсн 32-разрнднБ1ми 
числами. 
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Такие спроецированнме типм вмглнднт более естественно длн разработчиков CLR. 
В качестве примеров можно привести структурм Point, Rect, Size и TimeSpan, 
определеннме в пространстве имен Windows . Foundation. 

Null -совместимме структурм. В рамках WinRT API также могут определитБСи 
пи11-совместимБ1е структурБ 1 (значимћге типб 1 ). CLR проецирует интерфеис WinRT 
Windows . Foundation . IReference<T> как тип CLR System.Nullable<T>. 

Перечисленин. Значении перечислимБ 1 х типов передаготси просто в виде 
32-разридного целого числа со знаком или без. Если bbi определлете перечислл- 
емвш тип в С#, он должен базироватвсл на типе int или uint. Кроме того, 32-раз- 
рад|Њ1С без знака интерпретируготси как флаги, которБ1е могут обБединлтБСл 
операциеи ИЛИ. 

ИнтерфеисБп В типах параметров и возврагцаемБгх значении интерфеисов 
WinRT могут исполБЗОватБСн толбко \V1 n RT'-co н местим p.i е типбк 

Методм. В WinRT реализована ограниченнан перегрузка методов. А именно, 
посколБку нзб 1 К JavaScript исполкзует динамическуго типизациго, он не умеет раз- 
личатБ методБц различагогциеси толбко по типам параметров. Например, JavaScript 
преспокоино передаст число методу, ожидагогцему получитв строку. Однако 
JavaScript отличит метод с одним параметром от метода с двуми параметрами. 
Кроме того, WinRT не поддерживает методБ 1 перегрузки операторов и значении 
аргументов по умолчаниго. 

Своиства. В качестве типа даннБ 1 х своиств WinRT могут задаватвсл толбко 
WinRT-coBMecTHMKie типбг WinRT не поддерживает параметризованнме своиства 
и своиства, доступнме толбко дли записи. 

ДелегатБГ В типах параметров и возврагцаемБ 1 х значении делегатов WinRT 
могут исполБЗОватБСл толбко \\1 n RT-coiimcci и м где типБг При передаче делегата 
компоненту WinRT обвект делегата упаковмваетсл в CCW и не уничтожаетсл 
уборгциком мусора до тех пор, пока обертка CCW не будет освобождена исполб- 
зугогцим ее компонентом WinRT. ДелегатБ 1 WinRT не имегот методов Beginlnvoke 
и Endlnvoke. 

Собмтии. Компонентм WinRT могут определнтв со6бгтил, исполБзул типб 1 
делегатов WinRT. Так как многие компонентм WinRT запечатанм (не допускагот 
наследование), в WinRT определиетсл делегат TypedEventHandlen, у которого па- 
раметр sender относитсн к обобгценному типу (вместо System.0bject). 

public delegate void TypedEventHandler<TSenderj TResult>(TSender sender, 

TResult args); 

Также сугцествует тип делегата Windows . Foundation. EventHandler<T>, ко- 
Topnrii CLR проецирует на знакомвги тип делегата .NET Framework System. 
EventHandler<T>. 

Исклгоченин. Bo внутреннеи реализацгш компонентБ 1 WinRT, как и компонентм 
СОМ, передагот информациго о своем состоннгш в значешшх HRESULT (32-разрид- 
ное целое число со специалвнои семантикои). CLR проецирует значенгш WinRT 
типа Windows . Foundation . HResult на обвектм исклгоченгш. Когда WinRT API 
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возвратцает значение HRESULT, заведомо соответствугошее ошибке, CLR вмдает зк- 
земплнр соответствуклцего класса, производного от Exception. Например, HRESULT 
0х8007000е (E_OUTOFMEMORY) отображаетси на System.OutOfMemoryException. Длн 
другихкодов HRESULT CLR вмдает обвект System. Exception, у которого своиство 
HResult содержит значение HRESULT. Компонент WinRT, реализованнми на С#, 
может просто вБвдатБ исклгочение нужного типа, а CLR преобразует его в соответ- 
ствугогцее значение HRESULT. Чтобм полностбго контролироватБ значение HRESULT, 
создаите обвект исклгоченил, задаите соответствугогцее значение HRESULT в своистве 
HResult обвекта, после чего вмдаите обвект исклгоченгш. 

Строки. Конечно, неизмениемме строки могут передаватБСи между системами 
типов WinRT и CLR. Тем не менее система типов WinRT не разрешает строкам при- 
ниматБ значение null. Если передатБ null в строковом параметре функции WinRT 
API, CLR обнаруживает зтот факт и вмдает исклгочение ArgumentNullException; 
вместо null дли передачи пустои строки функцгшм WinRT API следует исполбзо- 
ватБ String . Empty. Строки передаготси по ссмлке; возврагцение строк функцгшми 
WinRT API всегда сопровождаетсл их копированием. При передаче или получении 
строковмхмассивов CLR (Stringf]) от функции WinRT API создаетсн копгш мас- 
сива, котораи передаетсл или возврагцаетсл на сторону вмзова. 

Дата и времн. Структура WinRT Windows.Foundation.DateTime представли- 
ет дату/времн в формате UTC. CLR проецирует структуру WinRT DateTime на 
структуру ,NET Framework System.DateTimeOffset, которуго следует исполбзо- 
ватБ вместо структурвг .NET Framework System. DateTime. B итоговом зкземшшре 
DateTimeOff set CLR преобразует дату и времи UTC, возврагцаемвге WinRT, в ло- 
калвное времн. CLR передает функцгшм WinRT API структуру DateTimeOffet 
с временем UTC. 

URI. CLR проецирует тип WinRT Windows . Foundation . Uri на тип .NET 
Framework System.Uri. Если при передаче типа .NET Framework Uri функцгш 
WinRT API исполБзуетсн относителБНБш URI -адрес, среда CLR вБгдает исклгочение 
ArgumentException; WinRT поддерживает толбко абсолготнБге URI. Переходчерез 
границБг взаимодеиствии всегда сопровождаетси копированием URI. 

IClosable/IDisposable CLRnpoeunpyeT интерфеис WinRT Windows. Foundation. 
IClosable (состонгции из единственного метода Close) на интерфеис .NET 
Framework System . IDisposable (содержагции метод Dispose). Следует учеств, 
что все функции WinRT API, вмполннгогцие операции ввода-вмвода, реализованм 
асинхронно. Так как метод интерфеиса IClosable назмваетсн Close, а не CloseAsync, 
метод Close не должен вмполнитб никакие операции ввода-вБгвода. В зтом он се- 
мантически отличаетсл от типичного поведенгш Dispose в .NET Framework. Длл 
типов, реализованнБгх в .NET Framework, метод Dispose может вбгполннтб операции 
ввода-вБгвода; более того, часто он обеспечивает записБ буферизованнБгх даннБгх 
перед фактическим закркгтием устроиства. Но когда код C# вБгзвгвает Dispose длл 
тггпа WinRT, операцгггг ввода-ввгвода (в частности, запггсв буферггзованнБгх даннБгх) 
вбгполннтбсн нс будут, что может привести к возможнои потере даннвгх. Вбг должнбг 
учитБгватБ зто обстолтелБСтво гг нвно вБгзвгватБ методБг, предотврагцагогцгге потерго 
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даннмх, длл компонентов WinRT, инкапсулиругондих потоки вмвода. Например, при 
исполвзовании обвекта DataWriter всегда следует вмзмватБ его метод StoreAsync. 

Массивм. В WinRT API поддерживаготсл одномернБге массивБ 1 с индексиро- 
ванием от нули. WinRT может передаватБ злементБ 1 массива либо в метод, либо из 
него — но никогда в обоих направлентшх. Соответственно bbi не сможете передатв 
массив функции WinRT API, изменитв злементБ 1 массива, а затем обратитвсл 
к измененнБш злементам после возврагценгш из функции АРР. Впрочем, н описал 
контракт, которвш должен соблгодатБсн. Тем не менее среда не занимаетсл актив- 
нб1м контролем его соблгоденгш, позтому некоторнге проекции могут передаватн 
содержимое массива в обоих направленгшх. Обвшно зто делаетсл длн естественного 
повБшгенгш произв одителвности. 

Коллекции. При передаче коллекции WinRT API среда CLR упаковБшает обв- 
ект коллекции в обертку CCW и передает ссвшку на CCW функции WinRT API. 
При вмзовах через CCW вмзмвагогции поток пересекает границу взаимодеиствгш, 
что приводит к снижениго производителБности. С другои сторонБр в отличие от 
массивов, при передаче коллекции WinRT API возможно вмполнение операции 
с коллекцгшми «на месте» без копировангш злементов. В табл. 25.1 перечисленм 
интерфеисм коллекции WinRT и их проекцгш в коде приложении .NET. 


Таблица 25.1 . ИнтерфеисБ! коллекции WinRT и их проекции в CLR 


Тип коллекции WinRT (пространство 
имен (Windows.Foundation. 
Collections) 

Проецируемми тип коллекции CLR 
(пространство имен System.Collections. 
Generic) 

IIterable<T> 

IEnumerable<T> 

IVector<T> 

IList<T> 

IVectorView<T> 

IReadOnlyList<T> 

IMap<K, V> 

IDictionary<TKey, TValue> 

IMapView<K, V> 

IReadOnlyDictionary<TKey, TValue> 

IKeyValuePair<K, V> 

KeyValuePair<TKey, TValue> 


Как показмвает приведеннми список, команда CLR основателвно потрудиласн 
над тем, что6б1 по возможности упроститв взаимодеиствие между системои типов 


1 Например, из зтого следует, что API не может содержатћ такие методн, как Sort класса 
System.Array. Интересно, что все лзбгки (С, С++, С#, Visual Basic и JavaScript) поддерживагот 
передачу злементов массива в обоих направленгшх, а система типов WinRT такои возмож- 
ности не дает. 
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WinRT и системои типов CLR, а разработчики управлнемого кода могли бм ис- 
полг>зоватБ компонентБ! WinRT в своем коде 1 . 


Проекции уровнл .NET Framework 

Если CLR не может ненвно подобратв проекцшо типа WinRT длл разработчика .NET 
Framework, приходитсл исполБЗОватБ нвнБге проекции. Естб три основнБге области, 
в которвгх необходимБг проекции: асинхронное программирование, взаимодеиствие 
между потоками WinRT и .NET Framework, а также передача блоков даннвгх между 
функцинми CLR и WinRT API. Зти три области более подробно рассматриваготсл 
в следуготих трех разделах зтои главБт 


Асинхроннме вмзовм WinRT API из кода .NET 

Синхронное вБшолнение операции ввода-вБгвода в программном потоке может 
привести к его блокировке на неопределеннвш период времени. Если поток гра- 
фического интерфеиса ожидает завершенгш синхроннои операции ввода/ввшода, 
полБЗОвателБСКии интерфеис приложенин перестает реагироватБ на деиствин 
полвзователл (операции с сенсорнвш зкраном, мбгшбго и пером), а зто раздражает 
полБЗОвателл. Чтобвг предотвратитв подобнуго блокировку, компонентвг WinRT, 
вБшолннгогцие операции ввода-вБшода, предоставлигот доступ к своеи функцио- 
налБности через асинхроннБш программнБпг интерфеис. Более того, компонентБг 
WinRT, вБшолннгогцие вБгчислителБшле операции, также предоставлигот доступ к 
своеи функционалБности через асинхроннБпг программнБш интерфеис, если вбг- 
полнение операцгпг занимает более 50 миллисекунд. Проблемнг построенгш при- 
ложении, бнгстро реагиругогцих на деиствгш полвзователн, также рассматриваготсл 
в части V зтои книги. 

Чтобвг зффектггвно ггсполвзоватБ многочисленнБге асинхроннБге функции WinRT 
API, необходимо пониматБ, как правилБно работатн с ними в коде С#. Рассмотрим 
следугогции пример: 

public void WinRTAsyncIntro( ) { 

IAsyncOperation<StorageFile> asyncOp = 

KnownFolders.MusicLibnary.GetFileAsync("Song.mp3"); 
asyncOp.Completed = OpCompleted; 

// Возможно, позднее будет вмзван метод asyncOp.Cancel() 

} 

// ВНИМАНИЕ: метод обратного вмзова вмполнветсн в программном потоке 
// графического интерфеиса или пула потоков: 

прооолжение 

1 Чтоби получитБ дополнителБнуго информациго по зтои теме, откроите страницу http: // 
msdn.microsoft.com/en-iis/library/windows/apps/hh995050.aspx и загрузите документ 
CLRandtheWindowsRuntime.docx. 
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private void OpCompleted(IAsyncOperation<StorageFile> asyncOpj AsyncStatus status) 

{ 

switch (status) { 

case AsyncStatus.Completed: // Обработка резулБтата 

StorageFile file = asyncOp.GetResults(); /* Завершено... */ break; 

case AsyncStatus.Canceled: // Обработка отменн 

/* Canceled... */ break; 

case AsyncStatus. Error: // Обработка исклнзченив 

Exception exception = asyncOp.ErrorCode; /* Ошибка... */ break; 

} 

asyncOp.Close(); 

} 

Метод WinRTAsyncIntro вмзмвает метод WinRT GetFileAsync длн поиска фаила 
в медиатеке полвзователн. Все функции WinRT API, вмполннклцие асинхроннме 
операции, имекзт суффикс Async и возврапдагот обвект, тип которого реализует ин- 
терфеис WinRT IAsyncXxx; в данном случае интерфеис IAsyncOperation<TResult>, 
где TResult — тип WinRT StorageFile. Зтот обвект, ссмлку накоторми н поместил 
в переменнуго asyncOp, представлиет незавершеннуго асинхроннуго операциго. 
Ваш код должен каким-то образом получитБ уведомление о завершении операции. 
Длн зтого необходимо реализоватБ метод обратного вБИОва (OpCompleted в моем 
примере), создатв длл него делегата и задатн делегата своиству Completed обвекта 
asyncOp. Теперв при завершении операции метод обратного ввгоова будет активи- 
зирован каким-либо потоком (необнзателвно потоком графического интерфеиса). 
Если операцгш бмла завершена перед назначением делегата своиству OnCompleted, 
система ввгоовет метод обратного ввгоова как можно бв 1 стрее. Другими словами, 
здесв возникает ситуацгш гонки, но обвект, реализугогции интерфеис IAsyncXxx, 
разрешит ее за вас, обеспечиван правилвностБ работБ1 кода. 

Как указано в конце метода WinRTAsyncIntro, длл отменБ 1 незавереннои операции 
также можно ввговатБ метод Cancel, реализуемБпг всеми интерфеисами IAsyncXxx. 
Все асинхроннБШ операции завершаготсн по однои из трех причин: успешного bbi- 
полненин операции до конца, нвнои отменБ1 или ошибки при вБшолнении операции. 
При завершении операции по однои из зтих причин система ввгоБшает метод об- 
ратного вБГООва и передает ему ссвшку на обвект, возврагценнБп) исходнбш методом 
XxxAsync, и AsyncStatus. Moir метод OnCompleted провернет параметр status 
и обрабатвшает либо резулБтат при успешном завершении, либо ивнуго отмену, 
либо ошибку 1 . Также обратите внимание на то, что после обработки завершенгш 
операции длл обвекта интерфеиса IAsyncXxx необходимо ввговатв метод Close. 


1 Интерфеис IAsyncInfo предоставллет своиство Status, которое содержит значение, пере- 
данное в параметре status метода обратного вмзова. Так как параметр передаетсн по значеншо, 
обратцение к параметру (вместо запроса своиства Status) улучшит производителБноств при- 
ложенгш, потому что обратцение к своиству приводит к вмзову функции WinRT API через 
RCW. 
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На рис. 25.2 изображенм различнме интерфеисм WinRT IAsyncXxx. Все четм- 
ре главнмх интерфеиса происходлт от интерфеиса IAsyncInfo. Два интерфеиса 
IAsyncAction предоставлигот возможностб узнатБ о завершении операции, но их 
операции завершаготси без возврагцаемого значенин (их методм GetResults воз- 
врагцагот void). Два интерфеиса IAsyncOperation позволнгот не толбко узнатг> о за- 
вершении операции, но и получитћ возврагцаемое значение (их методм GetResults 
возврагцагот обобгценнми тип TResult). 

Два интерфеиса IAsyncXxxWithProgress позволигот коду получатБ перио- 
дические оповегценгш о ходе вмполненгш асинхроннои операции. Болбшинство 
асинхроннмх операции не поддерживает оповегценгш, но у некотормх видов опе- 
рации (как, например, у фоновои загрузки и отправки даннмх) такаи возможностг. 
предусмотрена. Длл полученин оповегцении следует определитБ в коде егце один 
метод обратного вмзова, создатг. длл него делегата и назначитБ его своиству Progress 
обвекта IAsyncXxxWithProgress. При обрагцении кметоду обратного вмзовапере- 
даетсл аргумент, тип которого соответствует обобгценному типу TProgress. 



Рис. 25.2. Интерфеисв! WinRT, относаш,иеса к ввшолненикз асинхронного 
ввода-вв 1 вода и вв 1 числителвннх операции 

В .NET Framework дли упрогценгш асинхроннмх операции исполБзуготсн типм 
из пространства имен System.Threading.Tasks. Типм дли вмполнешш асин- 
хроннмх вмчислении и их исполг>зование рассматриваготсл в главе 27, а типм длл 
вмполненгш асинхронного ввода-вмвода — в главе 28. Кроме того, в C# имеготсн 
клгочевме слова async и await, которме позволнгот вмполннтб асинхроннме опе- 
рации с применением модели последователг>ного программировангш, сутцественно 
упрогцагогцеи структуру кода. 

Следугогции код представлнет собои переработаннуго версиго упоминавшегосн 
ранее метода WinRTAsyncIntro. В зтои версии задеиствованм некоторме методм 
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расширенин .NET Framework, преобразукицие моделћ асинхронного программи- 
ровангш WinRT в более удобнуго моделБ программировангш С#. 

using System; // Необходимо длд методов расширенид 

// из WindowsRuntimeSystemExtensions 

public async void WinRTAsyncIntno() { 
try { 

StonageFile file = await KnownFoldens.MusicLibrary.GetFileAsync("Song.mp3"); 

/* Завершение ... */ 

} 

catch (OperationCanceledException) { /* Отмена... */ } 
catch (SomeOtherException ех) { /* Ошибка... */ } 


Оператор C# await заставллет компиллтор провести поиск метода GetAwaiter 
в интерфеисе IAsyncOperation<StorageFile>, возврагценном методом GetFileAsync. 
Интерфеис не предоставлнет метод GetAwaiter, позтому компшштор игцет метод 
расширенгш. К счастг>го, разработчик ,NET Framework вклгочили в библиотеку 
System.Runtime.WindowsRuntime.dll методћг расширенин, вБИБгваемБге длл интер- 
феисов WinRT IAsyncXxx. 

namespace System { 

public static class WindowsRuntimeSystemExtensions { 

public static TaskAwaiter GetAwaiter(this IAsyncAction source); 
public static TaskAwaiter GetAwaiter<TProgress>(this 
IAsyncActionWithProgress<TProgress> source); 
public static TaskAwaiter<TResult> GetAwaiter<TResult>(this 
IAsyncOperation<TResult> source); 

public static TaskAwaiter<TResult> GetAwaiter<TResult, TProgress>( 

this IAsyncOperationWithProgress<TResult, TProgress> source); 

} 

} 

Bo внутреннеи реализации все зти методвг создагот обвект TaskCompletionSource 
и приказБгвагот обвекту IAsyncXxx обратитвсн к методу обратного вкгзова, которвш 
задает финалвное состолние TaskCompletionSource при завершении асинхроннои 
операции. Обвект TaskAwaiter, возврагцаемвш методами расширенин — то, что 
в конечном счете должен получитв С#. При завершении асинхроннои операции 
обвект TaskAwaiter следит за тем, чтобвг код продолжал вбгполннтбси через 
обвект SynchronizationContext (см. главу 28), свнзаннвш с исходнбгм потоком. 
Затем поток вБгполннет код, сгенерированнБги компшштором С#, которБш за- 
прашивает своиство Result обвекта TaskCompletionSource.Task; зто приводит 
к получениго резулвтата (StorageFile в моем примере), ввгдаче исклгоченил 
OperationCanceledException в случае отменвг или другого исклгоченгш в случае 
ошибки. Пример внутреннеи реализации зтих методов приведен в конце раздела. 

Мбг рассмотрели наиболее типичнбги сценарии внгзова асинхроннои функции 
WinRT API и определенгш резулвтата. Однако в своем коде н показал, как узнатв 
об отмене операции, но не о6бнснил, как на практике производитсл отмена. Также 
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осталсн нерассмотреннмм вопрос обработки оповешении о ходе вмполнешш опе- 
рации. Чтобм правилБно обработатБ отмену и оповешенин, вместо автоматического 
вмзова компиллтором одного из методов расширенгш GetAwaiter следует нвно 
вмзватБ один из методов расширешш AsTask, также ивно определиеммх классом 

WindowsRuntimeSystemExtensions. 

namespace System { 

public static class WindowsRuntimeSystemExtensions { 
public static Task AsTask<TProgress>(this 

IAsyncActionWithProgress<TProgress> source, 

CancellationToken cancellationToken, IProgress<TProgress> progress); 

public static Task<TResult> AsTask<TResult, TProgress>( 

this IAsyncOperationWithProgress<TResult, TProgress> source, 
CancellationToken cancellationToken, IProgress<TProgress> progress); 

// Более простте перегруженние версии не показани 

} 

} 

Итак, порарассмотретБреализацшо в целом. Вот как происходит асипхрошњш 
ВБ130В функции WinRT API с полнои поддержкои отменв 1 и оповегцении о ходе 
вБшолненгш в тех случанх, когда они необходимБП 

using System; // Длн AsTask из WindowsRuntimeSystemExtensions 
using System.Threading; // Длн CancellationTokenSource 
internal sealed class MyClass { 

private CancellationTokenSource m_cts = new CancellationTokenSource(); 

// ВНИМАНИЕ: при визове из потока графического интерфеиса 
// Becb код виполнветсл в зтом потоке: 

private async void MappingWinRTAsyncToDotNet(WinRTType someWinRTObj) { 
try { 

// Предполагаетсн, что XxxAsync возврацает 
// IAsyncOperationWithProgress<IBuffer, UInt32> 

IBuffer result = await someWinRTObj.XxxAsync(...) 

.AsTask(m_cts.Token, new Progress<UInt32>(ProgressReport)); 

/* Завершение ... */ 

} 

catch (OperationCanceledException) { /* Отмена... */ } 
catch (SomeOtherException) { /* Ошибка... */ } 

} 

private void ProgressReport(UInt32 progress) { /* Оповецение. .. */ } 
public void Cancel() { m_cts.Cancel(); } // Вшзшваетсд позднее 

} 

Конечно, многим читателлм хотелосн 6б1 понлтб, как методБ 1 AsTa s k преобразугот 
oo'bCKT WinRT IAsyncXxx в обвект ,NET Framework Task, к которому в конечном 
итоге применнетсн await. В следугогцем коде представлена внутренннн реализацин 
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самого сложного метода AsTask. Конечно, более простме перегруженнме версии 
устроенм проше. 

public static Task<TResult> AsTask<TResult л TProgress>( 

this IAsyncOperationWithProgress<TResult, TProgress> asyncOp, 

CancellationToken ct = default(CancellationToken), 

IProgress<TProgress> progress = null) { 

// При отмене CancellationTokenSource отменити асинхроннув операциш 
ct . Register( () => asyncOp.Cancel()); 

// Когда асинхроннал операцил оповешает о прогрессе, 

// оповевдение передаетсл методу обратного вћвова 
asyncOp.Progress = (asyncInfo, р) => progress . Report(p) ; 

// Обцект TaskCompletionSource наблтдает за завершением 
// асинхроннои операции 

var tcs = new TaskCompletionSource<TResult>( ); 

// При завершении асинхроннои операции оповеститц TaskCompletionSource . 

// Когда зто происходит, управление возврашаетсл коду, 

// ожидакпцему завершенил TaskCompletionSource. 
asyncOp.Completed = (asyncOp2, asyncStatus) => { 
switch (asyncStatus) { 

case AsyncStatus.Completed: tcs.SetResult(asyncOp2.GetResults()); break; 

case AsyncStatus.Canceled: tcs.SetCanceled(); break; 

case AsyncStatus.Error: tcs.SetException(asyncOp2.ErrorCode); break; 

} 

}; 


return tcs.Task; 

} 


Взаимодеиствил между потоками WinRT и потоками .NET 

Многие классм .NET Framework работагот с типами, производнмми от System. 
10. Stneam — как, например, классм сериализации и LINQ. Чтобм исполБЗОватБ о6ђ- 
ект WinRT, реализугошии интерфеисБ 1 WinRT IStorageFile или IStorageFolden, 
с классом .NET Framework, которому необходим тип, производнБш от Stream, 
следует задеиствоватБ методБ 1 расширенгш, определеннБШ в классе System.IO.Wi 
ndowsRuntimeStorageExtensions. 

namespace System.I0 { // Определлетсл в System.Runtime.WindowsRuntime.dll 

public static class WindowsRuntimeStorageExtensions { 

public static Task<Stream> OpenStreamForReadAsync(this IStorageFile file); 
public static Task<Stream> OpenStreamForWriteAsync(this IStorageFile file); 

public static Task<Stream> OpenStreamForReadAsync(this 
IStorageFolder rootDirectory, 

String relativePath); 

public static Task<Stream> OpenStreamForWriteAsync(this 
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IStorageFolder rootDirectoryj 

String relativePathj CreationCollisionOption creationCollisionOption); 

} 

} 

B следуклцем примере один из методов расширенин исполБзуетсн длн открмтин 
обвекта WinRT StorageFile и чтенин его содержимого в обвект ,NET Framework 
XElement. 

async Task<XElement> FromStorageFileToXElement(StorageFile file) { 
using (Stream stream = await file.OpenStreamForReadAsync()) { 
return XElement.toad(stream); 

} 

} 

Наконец, класс System.IO.WindowsRuntimeStreamExtensions предоставллет 
методм расширешш, <<преобразуклцие» потоковме интерфеисм WinRT (такие, как 
IRandomAccessStream, IlnputStream или IOutputStream) в тип .NET Framework 
Stream, и наоборот. 

namespace System.IO { // Определпетсл в System.Runtime.WindowsRuntime.dll 

public static class WindowsRuntimeStreamExtensions { 

public static Stream AsStream(this IRandomAccessStream winRTStream); 
public static Stream AsStream(this IRandomAccessStream winRTStream, 

Int32 bufferSize); 

public static Stream AsStreamForRead(this IlnputStream winRTStream); 
public static Stream AsStreamForRead(this IlnputStream winRTStream, 

Int32 bufferSize); 

public static Stream AsStreamForWrite(this IOutputStream winRTStream); 
public static Stream AsStreamForWrite(this IOutputStream winRTStream, 

Int32 bufferSize); 

public static IlnputStream AsInputStream (this Stream clrStream); 
public static IOutputStream AsOutputStream(this Stream clrStream); 

} 

} 

B следуклцем примере один из методов расширешш исполБзуетсл длл «преоб- 
разовашш» обвекта WinRT IlnputStream в обвект ,NET Framework Stream. 

XElement FromWinRTStreamToXElement(IInputStream winRTStream) { 

Stream netStream = winRTStream.AsStreamForRead(); 
return XElement.Eoad(netStream); 

} 

Обратите внимание: методБ 1 <<преобразованил», предоставллемБ 1 е .NET 
Framework, не ограничивакзтсл простБ 1 м внутренним преобразованием типа. Ме- 
тодб1, адаптируклцие потоки WinRT в потоки ,NET Framework, нелвно создагот 
буфер длл потока WinRT в управллемои куче. В резулвтате 6олбшинство операции 
осугцествллет записв в буфер и не нуждаетсл в пересечении границБ 1 взаимодеи- 
ствил, что способствует повБ1шениго производителБности — зто особенно важно 
в ситуацилх с многочисленнвши мелкими операцилми ввода-вБшода (например, 
при разборе документа XML). 
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Одно из преимушеств исполБЗОванин проекции потоков .NET Framework за- 
клгочаетсл в том, что если метод исполБзуетсл более одного раза длл AsStneamXxx 
длн одного зкземплира потока WinRT, вам не придетсл беспокоитћсн о возможно- 
сти создангш несколвких разнБ1х буферов и о том, что даннвге, записаннБге в один 
буфер, не будут виднб1 в другом. Функции ,NET Framework API следлт за тем, 
что6б1 каждБш обвект потока исполкзовал уникалвнБш зкземплир адаптера, а все 
полБЗОватели работали с одним буфером. 

И хотн в болБшинстве случаев стандартнан буферизацгш обеспечивает хорошии 
компромисс между производителвностБГО и затратами памлти, иногда требуетсл 
изменитБ 16-килобаитнБш размер буфера, исполБзуемБш по умолчаниго. МетодБг 
AsStreamXxx предоставлнгот перегруженнБге версии с такои возможностбго. На- 
пример, если вбг знаете, что будете работати с оченБ 6олбшим фаилом в течение 
длителБного времени, а количество одновременно исполвзуемБгх других буфери- 
зованнБгх потоков будет неболвшим, вбг сможете обеспечитБ некоторБпг прирост 
производителБности, вБгделив длн своего потока оченв 6олбшои буфер. И наобо- 
рот, в некоторвгх ситуацилх с необходимостБГО минималБнои задержки можно 
потребоватБ, что6бг из сети читалосБ ровно столбко баитов, сколбко необходимо 
приложениго; тогда буферизациго можно вообгце отклгочитб. Если передатБ методу 
AsStreamXxx нулевои размер буфера, то обвект буфера не создаетсл. 

Передача блоков даннмх между CLR и WinRT 

Там, где зто возможно, рекомендуетсн исполвзоватБ проекции потоков из предввду- 
вдего раздела, потому что они обладагот достаточно хорошими характеристиками 
производителБности. Однако некоторкге ситуации требугот передачи между CLR 
и компонентами WinRT физических блоков даннмх. Например, при исполБЗОваиии 
компонентов фаиловвгх и сокетовигх потоков WinRT необходимо вбшолинтб чтение 
и записБ физических блоков даншлх. Кроме того, криптографические компонентБ 1 
WinRT вбшолнпгот шифрование и дешифрование блоков даннвгх, а пикселБ 1 рас- 
тровои графики также хранитси в виде физических блоков даннБгх. 

В ,NET Framework блоки даннкгх о6бгчно передаготсл в виде массива баитов 
(Byte [ ]) или в виде потока (например, при исполБЗОвании класса MemoryStream). 
Конечно, массивБг баитов и обвектБ1 MemoryStream не могут передаватБСн компо- 
нентам WinRT напрнмуго, позтому WinRT определнет интерфеис IBuffer; обБектм, 
реализуговдие зтот интерфеис, представлшот физические блоки даннвгх, которБге 
могут передаватБСи функцинм WinRT API. Интерфеис WinRT IBuffer определн- 
етсл следуговдим образом: 

namespace Windows.Storage.Streams { 
public interface IBuffer { 

UInt32 Capacity { get; } // Максималинми размер буфера (в баитах) 

UInt32 Length { get; set; } // Количество исполБзуемух баитов 
} // в буфере 

} 
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Как видите, обвект IBuffen имеет максималћнми размер и текутцуго длину; как 
ни странно, он не предоставлнет средств длн вмполненин чтенин или записи даннмх 
в буфер. Зто обЂнсннетсл, прежде всего, тем, что типм WinRT не могут вмражатБ 
указатели в своих метаданнмх, потому что указатели плохо соответствугот пра- 
вилам некотормх нзмков (например, JavaScript или безопасного кода С#). Таким 
образом, oo'bcicr IBuffen — всего лишб способ передачи адреса памлти между CLR 
и WinRT API. Длн обрагценгш к баитам по адресу памити исполБзуетсл внутрен- 
нии интерфеис СОМ IBuffenByteAccess. Обратите внимание: зто интерфеис 
СОМ (потому что он возврагцает указателћ), а не интерфеис WinRT. Группа .NET 
Framework определила длл зтого интерфеиса СОМ внутреннгого обертку RCW, 
котораи вмгллдит примерно так: 

namespace System.Runtime.InteropServices.WindowsRuntime { 

[Guid("905a0fefbc5311df8c49001e4fc686da")] 

[InterfaceType(ComInterfaceType.InterfaceIsIUnknown)] 

[Comlmport] 

internal interface IBufferByteAccess { 
unsafe Byte* Buffer { get; } 

} 

} 

Bo внутреннеи реализации CLR может взитб оођскт IBuff en, запроситБ его ин- 
терфеис IBuffenByteAccess, а затемобратитБСи к своиству Buffen длн полученгш 
небезопасного указатели на баитм, содержагциесл в буфере. По зтому указателго 
к баитам можно обратитБСи напрнмуго. 

Чтобм избавитБ разработчиков от написангш небезопасного кода, работагогцего 
с указателнми, в FCL 6бгл вклгочен класс WindowsRuntimeBuffenExtensions. Он 
определлет набор методов расширенин, которвге цвно вБгзБгваготсл разработчи- 
ками длл передачи блоков даннвгх между массивами баитов и потоками CLR и 
обвектами WinRT IBuf f en. Длн исполБЗОвангш зтих методов расширенин следует 
вклгочитб в исходнбги код директиву using System . Runtime . IntenopSenvices. 
WindowsRuntime;: 

namespace System.Runtime.InteropServices.WindowsRuntime { 
public static class WindowsRuntimeBufferExtensions { 
public static IBuffer AsBuffer(this Byte[] source); 
public static IBuffer AsBuffer(this Byte[] source, Int32 offset, 

Int32 length); 

public static IBuffer AsBuffer(this Byte[] source, Int32 offset, 

Int32 length, Int32 capacity); 

public static IBuffer GetWindowsRuntimeBuffer(this MemoryStream stream); 
public static IBuffer GetWindowsRuntimeBuffer(this MemoryStream stream, 

Int32 position, Int32 length); 

} 

} 

Итак, если у вас имеетсл массив Byte[ ] и вбг хотите передатБ его функции 
WinRT, получагогцеи IBuffen, просто вБгзовите AsBuffen длл массива Byte[], 
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По сути, ссмлка на Byte[ ] упаковмваетсл в обвект, реализукпции интерфеис 
IBuffer; содержимое массива Byte[ ] при зтом не копируетсл, так что операцин 
вмполнпетсл оченБ зффективно. Аналогичнмм образом, если у вас имеетси обвект 
MemoryStream, в котором упакован буфер Byte[ ], вм просто вмзмваете длн него 
метод GetWindowsRuntimeBuffer, чтобм ссмлка на буфер MemoryStream бмла за- 
клгочена в обвект, реализукзшии интерфеис IBuffer. И снова содержимое буфера 
не копируетсл, позтому операцин обладает вмсокои зффективноствго. Следугондии 
метод демонстрирует обе ситуации: 

private async Task ByteArrayAndStreamToIBuffer(IRandomAccessStream winRTStream, 

Int32 count) { 

Byte[] bytes = new Byte[count]; 

await winRTStream.ReadAsync(bytes.AsBuffer(), (UInt32)bytes.Length, 
InputStreamOptions.None); 

Int32 sum = bytes.Sum(b => b); // Обратение к прочитаннмм баитам 

// через Byte[] 

using (var ms = new MemoryStream()) 
using (var sw = new StreamWriter(ms)) { 

sw.Write("This string represents data in a stream"); 
sw.Flush(); 

UInt32 bytesWritten = await 

winRTStream.WriteAsync(ms.GetWindowsRuntimeBuffer()); 

} 

} 

Интерфеис WinRT IRandomAccessStream реализует интерфеис WinRT Ilnput- 
Stream, определиемми следуговдим образом: 

namespace Windows.Storage.Streams { 

public interface IOutputStream : IDisposable { 

IAsync0perationWithProgress<UInt32, UInt32> WriteAsync(IBuffer buffer); 

} 

} 

Когда вм вмзмваете методм расширенин AsBuf fer или GetWindowsRuntimeBuff er 
в своем коде, зти методм упаковмвагот исходнми обвект в обвект, класс которого 
реализует интерфеис IBuff er. Затем CLR создает длн зтого обвекта обертку CCW 
и передает ее функции WinRT API. Когда функцин WinRT API запрашивает свои- 
ство Buffer интерфеиса IBufferByteAccess длн полученин указателл на массив 
баитов, массив фиксируетсл в памнти, а его адрес возврашаетсл WinRT API длн 
обрашенин к даннмм. Фиксацин снимаетсн, когда WinRT API вмзмвает метод СОМ 
Release длн интерфеиса IBufferByteAccess. 

Если BBi вмзмваете функциго WinRT API, возврашагошуго IBuffer, то, ско- 
рее всего, сами даннме находлтсл в неуправлиемои памнти, и вам нужен меха- 
низм обрашенил к зтим даннмм из управлиемого кода. Длл решенил зтои за- 
дачи следует обратитБсл к другим методам расиренил, определлемБш классом 
WindowsRuntimeBufferExtensions. 

namespace System.Runtime . InteropServices . WindowsRuntime { 
public static class WindowsRuntimeBufferExtensions { 
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public static Stream AsStream(this IBuffer source); 
public static Byte[] ToArray(this IBuffer source); 

public static Byte[] ToArray(this IBuffer source, UInt32 sourceIndex, 

Int32 count); 

// He показано: метод СоруТо длл передачи баитов между IBuffer и Byte[] 

// Не показано: методн GetByte, IsSameData 

} 

} 

Метод AsStream создает обЂект, производнми от Stream, которми служит оберт- 
Koii длн исходного обвекта IBuffer. При наличии такого обвекта можно обрагцатЂСн 
к даннмм IBuffer, вмзмван Read, Write и прочие подобнме методм Stream. Метод 
ТоАггау во внутреннеи реализации создает Byte [ ], после чего копирует все баитм 
из исходного обвекта IBuffer в Byte [ ]; учтите, что зтот метод расширенгш может 
дорого обходитБСн в отношении затрат памлти и процессорного времени. 

Класс WindowsRuntimeBufferExtensions также содержит несколБКО перегру- 
женнмх версии метода СоруТо, позволнкнцих копироватБ баитм между IBuffer 
и Byte [ ]; метод GetByte, читаклции даннме из IBuffer по одному баиту; и метод 
IsSameData, сравниваклции содержимое двух обвектов IBuffer. Врнд ли зти методм 
будут часто исполБЗОватБСн в ваших приложенинх. 

Также стоит упомннутв о том, что .NET Framework определлет класс System. 
Runtime . InteropServices . WindowsRuntimeBuff er длн созданин обвекта IBuff er, 
баитБ 1 которого находлтсн в управллемои куче. Также сугцествует компонент 
WinRT Windows . Storage . Streams. Buffer длл созданин обвекта IBuffer, баитБ 1 
которого находлтсл в системнои куче. Скорее всего, болвшинству разработчиков 
.NET Framework не придетсл исполвзоватБ зти классБ! в своем коде. 


Определение компонентов WinRT в коде C# 

До настонгцего момента рассматривалисв возможности исполвзованин компонентов 
WinRT в С#. Однако bbi также можете определитв компонентБ 1 WinRT в коде C# 
длл последуклцего исполвзовашш в С/С++, C#/Visual Basic, JavaScript и в других 
нзБгках. И хотл зто возможно, стоит разобратвси в том, в каких ситуацинх такое 
решение оправдано. Например, бессмвгсленно определнтБ компонент WinRT на С#, 
если он будет исполБЗОватБСи толбко в других управлнемвш нзБшах, работаклцих 
поверх CLR. Дело в том, что система типов WinRT обладает сугцественно менвшеи 
функционалБностБК), ограничиваклцеи ее возможности по сравненшо с системои 
типов CLR. 

Л также считаго, что бвшо 6bi неразумно реализоватв в коде C# компонент 
WinRT, предназначеннвпг длл исполБЗОвангш в неуправлнемом коде С/С++. Ско- 
рее всего, разработчики, пишугцие свои приложенгш на С/С++, силбно озабоченБ 1 
производителБностБго и/или затратами памити в своих приложенгшх. Врнд ли 
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они захотлт исполћзоватћ компонент WinRT, реализованнв 1 и на управлиемом 
коде, потому что зто потребует загрузки CLR в процесс, а следователћно, приведет 
к увеличеншо затрат памнти и снижениго производителБности из-за уборки мусора 
и Ј IT -компилиции кода. По зтои причине многие компонентм WinRT (вклгочаи 
компонентм, входнгцие в поставку Windows) реализованм в неуправлиемом коде. 
Конечно, в неуправлнеммх приложеничх С++ могут 6мтб части, не столг> критичнме 
по производителБности, и в некотормх ситуацинх привлечение функционалБности 
.NET Framework дли повмшенин продуктивности разработки оправдано. Напри- 
мер, сервис Bing Maps исполБзует неуправлнемБП! код С++ длч прорисовки своего 
полвзователБСКого интерфеиса с применением DirectX, а в реализации бизнес-ло- 
гики также применпетсл С#. 

Итак, по моему мнениго, компонентБ 1 WinRT, реализованнБге на С#, лучше всего 
подходлт длн разработчиков приложении Windows Store, которвге стролт полвзова- 
телвскии интерфеис средствами HTML и CSS, а затем исполвзугот JavaScript длн 
свнзБшанин интерфеиса с бизнес-логикои, реализованнои в виде компонента WinRT. 
Другои ВОЗМОЖНБ 1 И сценарии — исполБЗОвание функционалвности сугцествугогцих 
компонентов FCL из приложении HTML/JavaScript. 

Разработчики, работагогцие с HTML и JavaScript, уже готовбг к затратам памнти 
и снижениго производителБности, обусловленнБши исполБЗОванием браузерного 
идра. Скорее всего, дополнителвнБге затратБг памнти и снижение производителБ- 
ности из-за исполБЗОвангш CLR длл них не будут критичнвши. 

Построение компонента WinRT на C# начинаетсл с создангш в Microsoft Visual 
Studio проекта типа Windows Runtime Component. При зтом создаетсл вполне о6б1чнбпг 
проект библиотеки классов, однако компилитор C# будет запугцен с параметром 
команднои строки /t:winmdobj длл создангш фаила с расширением ,winmdobj. При 
наличии зтого параметра компилитор также генерирует частв IL -кода иначе, чем 
при обпшном запуске. Например, компонентБ 1 WinRT добавлигот и удалнгот деле- 
гатов собвгтии не так, как ото делает CLR, позтому компилнтор вклгочает другои 
код в методвг add и remove со6бгтии. Позднее в зтом разделе н покажу, как нвно 
реализоватв методБ1 add и remove со6б1тии. 

Когда компилнтор создаст фаил ,winmdobj, запускаетсн утилита зкспорта WinMD 
(WinMDExp.exe), которои передаготсл созданнпге компшштором фаилБ1 .winmdobj, 
.pdb и .xml (doc). nporpaMMaWinMDExp.exe анализирует метаданнБШ фаила и убеж- 
даетсп в том, что типбг соответствугот правилам систсм p>i типов WinRT (см. начало 
главБг). Она также измениет метаданнкге, содержагциесл в фаиле ,winmdobj; IL -код 
при зтом остаетсл неизменнвш. Говорн конкретнее, все типбг CLR отображагот- 
сл на зквивалентнБге типбг WinRT. Например, сспглка на тип ,NET Framework 
IList<String> заменлетсл ссбшкои на тип WinRT IVector<String>. Резулптат 
работБ1 WinMDExp.exe представллет собои фаил .winmd, которвш может исполбзо- 
ватБСи другими нзБшами программировангш. 

Содержимое фаила ,winmd можно просмотретв в программе ILDasm.exe. По умол- 
чангда программа ILDasm.exe вбшодит необработанное содержимое фаила, но с па- 



Определение компонентов VVinRT в коде C# 717 


раметром команднои строки /project она покажет, как будут вмглидетБ метаданнћге 
после проецированин типов WinRT на зквивалентнвге типбг .NET Framework. 

В следугогцем коде продемонстрирована реализацин различнвгх компонентов 
WinRT на С#. В компонентах задеиствованвг многие возможности, упоминавшие- 
СА в зтои главе, а многочисленнвге комментарии о6бисннк)т сутБ происходигцего. 
Если вам потребуетсн написатв компонент WinRT на С#, и рекомендуго взнтб при- 
веденнБпг код за образец. 

ВНИМАНИЕ 

Когда управлчемБ 1 и код исполБзует компонент WinRT, также написаннми на управ- 
лиемом коде, CLR рассматривает компонент WinRT так, как если бн он 6bm обнчннм 
управллеммм компонентом — то ести CLR не создает CCW и RCW, а следователБно, 
не вБ13Б1вает через них функции WinRT API. Зто приводит к заметному повмшеник) 
бнстродеиствич. Однако в процессе тестированич компонента функции API вн- 
змвак)тсч не так, как они вмзмвалисБ бм из других лзмков (скажем, из С/С++ или 
JavaScript). Таким образом, помимозаниженнмхзатратпамлти и сниженич произво- 
дителБности, управлчемми код может передатц null функции WinRT API, требукицеи 
String — и зто не приведет к вмдаче исклкзченич ArgumentNullException. Кроме того, 
функции WinRT API, реализованнБ 1 е в управлчемом коде, могут изменптц передан- 
нме массивм, и вмзмва 10 цдач сторонаувидит измененное содержимое массива при 
возврате управленич; оби 1 чно система TnnoBWinRT запреидаетизменение массивов, 
переданнмх функцич API. На практике вм столкнетесц и с другими различичми, так 
что будвге BHHMaTeabHbi. 


Модулц: WinRTComponents.cs 

Примечанил: Copyright (с) 2012 by Deffrey Richter 

using System; 

using System.Collections.Generic; 
using System.Linq; 

using System.Runtime.InteropServices.WindowsRuntime; 

using System.Threading; 

using System.Threading.Tasks; 

using Windows.Foundation; 

using Windows.Foundation.Metadata; 

// Пространство имен ДОЛЖНО соответствоватБ имени сборки 
// и 6biTb отличннм от "Windows" 
namespace Wintellect.WinRTComponents { 

// [Flags] // He должно бмти длл int; облзателино длл uint 
public enum WinRTEnum : int { // Перечисленин должнм базироватисн 

None, // на типе int или uint 

NotNone 

} 

// Структурм могут содержати толико основнне типм данннх, 
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// String и другие структурм. 

// Конструктори и методм запрешен|>1. 
public struct WinRTStruct { 
public Int32 ANumber; 
public String AString; 

public WinRTEnum AEnum; // B деиствителиности просто 
} // 32-разрпдное целое 

// В сигнатуре делегатов должнм содержатцсв WinRT-coBMecTHMbie типм 

// (без Beginlnvoke/Endlnvoke) 

public delegate String WinRTDelegate(Int32 х); 

// Интерфеисђ! могут содержатц методћц своиства и собћггив, 

// но не могут 6biTb обобтеннуми. 
public interface IWinRTInterface { 

// Nullable<T> продвигаетсл как IReference<T> 

Int32? InterfaceProperty { get; set; } 

} 

// MneHbi без атрибута [Version(#)] по умолчаник) исполБзутт версит 
// класса (1) и лвллгатсв частБК) одного нижележа[цего интерфеиса СОМ, 

// создаваемого программои WinMDExp.exe. 

[Version(l)] 

// Классм должнм 6biTb производнуми от Object, запечатаннмми, 

// не обобшеннмми, должнм реализовати толцко интерфеису WinRT, 

// а открмтме члени должнм 6biTb типами WinRT 
public sealed class WinRTClass : IWinRTInterface { 

// Открутме полв запрешенм 

ttregion Класс может предоставллти статические методи, своиства и собмтив 
public static String StaticMethod(String s) { return "Returning " + s; } 
public static WinRTStruct StaticProperty { get; set; } 

// B DavaScript параметри 'out' возвраша 1 отсл в виде обцектов; 

// каждми параметр становитсл своиством нарвду с возвратаеммм значением 
public static String OutParameters(out WinRTStruct х, out Int32 уеаг) { 
х = new WinRTStruct { AEnum = WinRTEnum.NotNone, ANumber = 333, 
AString = "Deff" }; 
уеаг = DateTimeOffset.Now.Year; 
return "Grant"; 

} 

#endregion 

// Конструктор может получати аргументм, кроме out/ref 

public WinRTClass(Int32? number) { InterfaceProperty = number; } 

public Int32? InterfaceProperty { get; set; } 

// Переопределлтвсв может толцко метод ToString 
public override String ToString() { 

return String.Format("InterfaceProperty={0}", 

InterfaceProperty.HasValue ? InterfaceProperty.Value.ToString() : 
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"(not set)"); 

} 

public void ThrowingMethod() { 

throw new InvalidOperationException("My exception message"); 

// Чтобн видатБ исклгачение c конкретннм кодом HRESULT, 

// исполнзуите COMException 

// const Int32 COR_E_INVALIDOPERATION = unchecked((Int32)0x80131509); 

//throw new COMException("Invalid Operation", COR_E_INVALIDOPERATION); 

} 

ttregion Массивм передакггсл, возврашаготсн ИЛИ заполннготсл; без комбинации 
public Int32 PassArray([ReadOnlyArray] /* Подразумеваетсл [In] */ 

Int32[] data) { 
return data.Sum(); 

} 

public Int32 FillArray([WriteOnlyArray] /* Подразумеваетсл [Out] */ 

Int32[] data) { 

for (Int32 n = 0; n < data.Length; n++) data[n] = n; 
return data.Length; 

} 

public Int32[] ReturnArray() { 
return new Int32[] { 1 , 2 , 3 }; 

} 

ttendregion 

// Коллекции передаготсл по ссмлке 

public void PassAndModifyCollection(IDictionary<String, Object> collection) { 
collection["Key2"] = "Value2"; // Коллекцип изменлетсл "на месте" 

} 

ttregion Перегрузка методов 

// Перегруженнме версии с одинаковнм количеством параметров 
// DavaScript считает идентичнв 1 ми 
public void SomeMethod(Int32 х) { } 

[Windows . Foundation.Metadata . DefaultOverload] // Метод назначаетсл 
public void SomeMethod(String s) { } // перегрузкои по умолчаниго 

ttendregion 

ttregion Автоматическан реализацил собнтип 
public event WinRTDelegate AutoEvent; 

public String RaiseAutoEvent(Int32 number) { 

WinRTDelegate d = AutoEvent; 

return (d == null) ? "No callbacks registered" : d(number); 

} 

ttendregion 

ttregion Ручнан реализацил собттил 
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// Закрнтое поле длл отслеживанил зарегистрированнмх делегатов собнтил 
private EventRegistrationTokenTable<WinRTDelegate> m_manualEvent = null; 

// Ручнал реализацил методов add и remove 
public event WinRTDelegate ManualEvent { 
add { 

// Получение сушествуккцеи таблицн (или создание новои, 

// если таблица euie не инициализирована) 
return EventRegistrationTokenTable<WinRTDelegate> 

.GetOrCreateEventRegistrationTokenTable(ref m_manualEvent) 

.AddEventHandler(value); 

} 

remove { 

EventRegistrationTokenTable<WinRTDelegate> 

.GetOrCreateEventRegistrationTokenTable(ref m_manualEvent) 

.RemoveEventHandler(value); 

} 

} 

public String RaiseManualEvent(Int32 number) { 

WinRTDelegate d = EventRegistrationTokenTable<WinRTDelegate> 
.GetOrCreateEventRegistrationTokenTable(ref 
m_manualEvent).InvocationList; 
return (d == null) ? "No callbacks registered" : d(number); 

} 

ttendregion 

ttregion Asynchronous methods 
// Асинхроннне методм ДОЛЖНН возврашатц 
// IAsync[Action|Operation](WithProgress) 

// ПРИМЕЧАНИЕ: другие лзнки видвт DataTimeOffset как 
// Windows . Foundation.DateTime 

public IAsyncOperationWithProgress<DateTimeOffsetj Int32> 
DoSomethingAsync() { 

// Исполцзуите методн Run класса 

// System.Runtime.InteropServices.WindowsRuntime.AsyncInfo 
// длл вћ13ова закрнтого методаЈ написанного исклтчителцно 
// на управллемом коде. 

return AsyncInfo.Run<DateTimeOffset, Int32>(DoSomethingAsyncInternal) 

} 

// Реализацил асинхроннои операции на базе закрмтого метода 
// с исполцзованием обнчннх технологии .NET 
private async Task<DateTimeOffset> DoSomethingAsyncInternal( 
CancellationToken ct, IProgress<Int32> progress) { 

for (Int32 х = 0; х < 10; x++) { 

// Поддержка отменм и оповешении о ходе внполненив 

ct . ThrowIfCancellationRequested (); 

if (progress != null) progress.Report(x * 10); 

await Task.Delay(1000); // Имитацил асинхроннмх операции 


} 
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neturn DateTimeOffset.Now; // Итоговое возврашаемое значение 

} 

public IAsyncOperation<DateTimeOffset> DoSomethingAsync2() { 

// Если отмена и оповешенил не нужнћр исполизуите 
// методм расширенил AsAsync[Action|Operation] 

// класса System.WindowsRuntimeSystemExtensions 
// (они Bbi3biBaK)T AsyncInfo.Run в своеи внутреннеи реализации) 
return DoSomethingAsyncInternal(default(CancellationToken), 
null).AsAsyncOperation(); 

} 

ttendregion 

// После распространенин версии новме членм следует помечатц 
// атрибутом [Version(#) ], чтобш программа WinMDExp.exe 
// помешала новше членш в другои интерфеис СОМ. Зто необходимоЈ 
// посколцку интерфеисш СОМ должнм 6biTb неизменнмми. 

[Version(2)] 

public void NewMethodAddedInV2( ) {} 

} 

} 

Следукпции код JavaScript демонстрирует обрагценин ко всем представленнмм 
компонентам и функцгмм WinRT. 

function () { 

// Длл удобства обрашенив к пространству имен в коде 
var WinRTComps = Nintellect.WinRTComponents; 

// Обрашение к статическому методу и своиству типа WinRT 

var s = WinRTComps.WinRTClass . staticMethod(null) ; // DavaScript передает "null"! 
var struct = { anumber: 123, astring: "Deff", aenum: 

WinRTComps.WinRTEnum.notNone }; 

WinRTComps.WinRTClass.staticProperty = struct; 
s = WinRTComps.WinRTClass.staticProperty; // Обратное чтение 

// Если метод имеет вшходнме параметрш, они и возврашаемое значение 

// передагатсл в виде своиств обБекта 

var s = WinRTComps.WinRTClass.outParameters(); 

var name = s.value; // Возврашаемое значение 

var struct = s.x; // Параметр 'out’ 

var уеаг = s.year; // Другои параметр 'out' 

// Создание зкземпллра компонента WinRT 

var winRTClass = new WinRTComps.WinRTClass(null); 

s = winRTClass.toString(); // Вмзов ToStringO 

// Вшдача и перехват исклтчении 
try { winRTClass.throwingMethod(); } 
catch (err) { } 

// Передача массива 
var a = [1, 2, 3, 4, 5]; 

продолжение & 
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var sum = winRTClass . passArray(a) ; 

// Заполнение массива 

var arrayOut = [7, 7, 7]; // ПРИМЕЧАНИЕ: fillArray видит нули! 

var length = winRTClass.fillArray(arrayOut); // При возврашении 

// arrayOut = [0, 1 , 2] 

// Возврацение массива 

a = winRTClass.returnArray(); // a = [ 1 , 2 , 3] 

// Передача коллекции c изменением злементов 

var localSettings = Windows.Storage.ApplicationData.current.localSettings 

localSettings.values["Keyl"] = "Valuel"; 

winRTClass.passAndModifyCollection(localSettings.values); 

// При возврашении localSettings.values содержит 2 парн "клк)ч/значение" 

// Bbi30B перегруженного метода 

winRTClass . someMethod(5); // Внзмвает SomeMethod(String), передавав 

// Исполнзование собмтил с автоматическои реализациеи 
var f = function (v) { return v.target; }; 
winRTClass.addEventListener("autoevent", f, false); 
s = winRTClass.raiseAutoEvent(7); 

// Исполцзование собмтив c ручнои реализациеи 
winRTClass.addEventListener("manualevent", f, false); 
s = winRTClass.raiseManualEvent(8); 

// Bbi30B асинхронного метода c поддержкои оповешении o ходе внполненив, 

// отменм и обработки ошибок 

var promise = winRTClass,doSomethingAsync() ; 

promise.then( 

function (result) { console.log("Async op complete: " + result); }, 
function (error) { console.log("Async op error: " + error); }, 
function (progress) { 

console.log("Async op progress: " + progress); 

//if (progress == 30) promise.cancel(); // Проверка отменш 

}); 


} 
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Глава 26. Потоки исполненил 


В зтои главе вм познакомитесБ с потоками исполненин, или просто потоки (threads) 1 . 
Мм поговорим о том, почему в Microsoft Windows понвиласБ концепцин потоков, 
о тенденцгшх развитин процессоров, о взаимоотношенинх потоков обгцензмковои 
исполнигогцеи средм (CLR -потоков) и Windows-noTOKOB, о дополнителБнмх за- 
тратах ресурсов при исполБЗОвании потоков, о планировании исполненгш потоков 
в Windows, о классах .NET Framework, предоставлигогцих доступ к своиствам по- 
токов, и о многом другом. 

В главах питои части книги обЂисннетси, каким образом Windows взаимодеи- 
ствует с CLR дли формировангш архитектурм потоков. НадегосБ, после прочтенгш 
зтих глав вм получите достаточно информации дли зффективного примененгш по- 
токов и создангш надежнмх, расширнеммх приложении и компонентов, оперативно 
реагиругогцих на деиствгш полБЗОвателл. 


Длч чего Windows поддерживает потоки? 

На заре компБготернои apbi операционнБге системБ 1 не поддерживали концепциго 
потоков. Точнее, сугцествовал всего один поток исполненгш, обслуживагогции как код 
операционнои системБц так и код приложении. В резулБтате задание, вБшолнение 
которого требовало времени, препнтствовало вБшолненгпо других задании. К при- 
меру, во времена 16-разрнднои системБ 1 Windows обБшнои 6bma ситуацгш, когда 
распечатБшагогцее документ приложение приостанавливало работу всеи машинБг 
Операционнаи система и осталБНБге приложенгш просто «зависали». А если вдруг 
в приложении возникала ошибка, которан приводила к бесконечному циклу, она 
вообгце порождала массу проблем. 

ПолБЗОвателго оставалосБ толбко перезагрузитБ компБготер, нажав кнопку Reset 
или ББШлгочателБ питангш. Разумеетси, полБЗОватели ненавидели такие ситуации 
(и продолжагот ненавидетБ до сих пор), потому что все запугценнБШ приложенгш 
при зтом авариино завершалисБ, а обрабатБ1ваемБ1е даннБге стиралисБ из памнти. 
В Microsoft понимали, что 16-разрнднан платформа Windows недостаточно хороша, 
что6б1 удержатБ компаниго на плаву в ходе далБнеишего развитии компБготернои 
индустрии, позтому 6бшо решено создатБ новуго операционнуго систему, удовлет- 
воригогцуго потребности как корпорации, так и отделБНБгх полБЗОвателеи. Она 
должна биша 6б1тб устоичивои, надежнои, расширнемои, безопаснои и избавленнои 


1 Не путатБ с потоками ввода-ВБтода (streams). — Примеч. ред. 
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от болћшинства недостатков своеи предшественницм. Лдро зтои операционнои 
системм впервме бмло вмпушено в составе Windows NT. С годами зто лдро пре- 
терпело множество обновлении и приобрело дополнителБнме возможности. По- 
следннн версин идра поставллетсл с последними версинми операционнмх систем 
Windows длн клиента и сервера. 

При разработке нового лдра операционнои системм бмло решено запускатБ 
каждми зкземплнр приложенгш в отделБном процессе (process). Процессом на- 
змваетсл набор ресурсов, исполБзуемми отделБнвш зкземплиром приложентш. 
Каждому процессу вБвделнетсл виртуалБное адресное пространство; зто гаранти- 
рует, что код и даннме одного процесса будут недоступнм дли другого. Зто делает 
приложенгш отказоустоичивмми, посколБку при таком подходе один процесс не 
может повредитБ код или даннБге другого. Код и даннБге ндра также недоступшл 
длн процессов; а значит, код приложении не в состоннии повредитБ код или даннБге 
операционнои системБг. Зто упрогцает работу конечнБгх полБЗОвателеи. Система 
становитсл также более безопаснои, потому что код произволБного приложенгш 
не имеет доступа к именам полБЗОвателеи, паролим, информации кредитнои картвг 
или ИНБ1М конфиденциалБНБш даннБш, с которБши работагот другие приложенгш 
или сама операционнаи система. 

А что с централБНБш процессором? Что если приложение воидет в бесконечнвш 
цикл? Если процессор всего один, приложение будет вбшолннтб зтот бесконечнБпг 
цикл и не сможет уделнтк внимание другим операцгшм. Несмотрн на очевиднвге 
преимугцества (неповрежденнвге даннБге и более вБгсокан степенк безопасности), 
система, как и ее предшественницБг, не сможет реагироватБ на деиствгш конечного 
полБЗОвателл. Дли решенгш зтои проблемвг и 6бгли придуманБг потоки. Именно 
поток стал тои концепциеи, котораи предназначена длл виртуализации процес- 
сора в Windows. Каждому Wi 11 ( I о ws- 11 |х) i i,cccy ввгделлетси собственнБпг поток ис- 
полненгш (которкш работает как виртуалБНБпг процессор). Если код приложенгш 
воидет в бесконечнБш цикл, то блокируетси толбко свизаннБпг с зтим кодом про- 
цесс, а осталБНБге процессБг (исполннгогциеси в собственнвгх потоках) продолжагот 
функционироватБ! 


РесурсоемкостБ потоков 

Потоки — замечателБное изобретение; ведБ именно благодарн им Windows реагирует 
на наши деиствгш даже несмотрн на то, что отделвнБге приложенгш могут 6бгтб за- 
нчтБг исполнением длителБНБгх задании. Кроме того, с помогцбго одного приложенгш 
(например, диспетчера задач) можно принудителБно прекратитБ работу другого при- 
ложенгш, если оно перестает отвечатБ на запросБг. Однако как и лго6бш механизмБг 
виртуализации, потоки потреблнгот дополнителБНБге ресурсБг, требун пространства 
(памлти) и времени (снижал производителБностБ средБг исполненгш). 

Рассмотрим ;■)■[■ и проблемБг более подробно. КаждБги поток состоит из несколк- 


ких частеи. 
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□ ОбЂект лдра потока (thread kernel object). Длн каждого созданного в неи потока 
операционнан система вмделлет и инициализирует одну из структур даннмх. 
Набор своиств зтои структурм (о них мм поговорим чутг> позже) описмвает по- 
ток. Структура содержит также так назмваемми контекст потока, то естБ блок 
памити с набором регистров процессора. На машине с процессором х86, х64 
и ARM контекст потока занимает около 700, 1240 и 350 баит соответственно. 

□ Блок окруженин потока (Thread Environment Block, ТЕВ). Зто место в памн- 
ти, вБгделенное и инициализированное в полћзователБСКом режиме (адресное 
пространство, к которому имеет 6p>iCTpp>in доступ код приложении). Зтот блок 
занимает одну страницу паммти (4 Кбаит длл процессоров х86, х64 и ARM). 
Он содержит заголовок цепочки обработки исклгочении. Каждвш блок tny, 
в которвпг входит поток, вставллет свои узел в начало цепочки. Когда поток bbi- 
ходит из блока try, узел из цепочки удаллетсл. Также ТЕВ содержит локалвное 
хранилигце даннБ1х дли потока и пекоторис структурБ1 даннБ1х, исполБзуемБге 
интерфеисом графических устроиств (GDI) и графикои OpenGL. 

□ Стек полБзователБского режима (user-mode stack). Применнетси длн храненнн 
передаваемБ1х в методБ1 локалБНБ1х переменнБ1х и аргументов. Также он содержит 
адрес, показБшагогции, откуда начнет исполнение поток после того, как текугции 
метод возвратит управление. По умолчаншо на каждвш стек полБЗОвателБСКого 
режима Windows вБвделнет 1 Мбаит памлти (а точнее, резервирует 1 Мбаит па- 
мнти и добавлнет физическуго памнтв по мере необходимости при росте стека). 

□ Стек режима ндра (kernel-mode stack). ИсполБзуетсл, когда код приложенгш 
передает аргументБ1 в функцшо операционнои системБц находнгцугосн в режиме 
ндра. Длл безопасности Windows копирует все аргументвц передаваемБт в идро 
кодом в полБЗОвателвском режиме, из стека потока полБЗОвателпского режима 
в стек режима ндра. После копированин ндро проверлет значенгш аргументов. 
Так как код приложенгш не имеет доступа к стеку режима ндра, приложение не 
в состоннии изменитв уже провереннБ1е аргументБц и с ними начинает рабо- 
татБ код ндра операционнои системБп Кроме того, идро вБ13Б1вает собственнвт 
методБ1 и исполБзует стек режима лдра длл передачи локалБНБ1х аргументов, 
а также длн сохраненгш локалвнБ1х переменнБ1х функции и обратного адреса. 
В 32-разрнднои версии Windows стек режима ндра занимает 12 Кбаит, а в 64-раз- 
риднои — 24 Кбаит. 

□ Уведомленин о создании и завершении потоков. Политика Windows такова, 
что если в процессе создаетси поток, то длн всех загруженнвш в зтот процесс 
DLL -библиотек вБ13Б1ваетсн метод DllMain и в него передаетсл флаг DLL_THREAD_ 
АТТАСН. Соответственно, при завершении потока зтому методу передаетсл уже 
флаг DLL_THREAD_DETACH. Получал уведомленгш об зтих собвтшх, некоторвт 
DLL -библиотеки вбгполнигот специалБНБге операции инициализации или 
очистки длл каждого созданного/завершенного в процессе потока. К примеру, 
DLL -библиотека C-Runtime вввделлет место под хранилигце локалБНБ 1 х состои- 
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нии потока, необходимое длн исполћзовании потоком функции из указаннои 
библиотеки. 

На заре развитин Windows в процесс загружалосБ 5 или 6 библиотек, в то времн 
как в наши дни некоторме процессм вклгочагот в себн несколБКО сотен библиотек. 
Скажем, в адресное пространство приложенгш Microsoft Visual Studio на моем 
компвготере загружено около 470 DLL -библиотек! Зто означает, что созданнми 
в данном приложении новми поток получит возможностб приступитБ к своеи 
работе толбко после вмзова 470 функции из DLL. По завершении потока в Visual 
Studio все зти функции будут вмзванм снова. Разумеетсл, зто не может не влинтб 
на производителћностБ создании и завершенгш потоков в процессе 1 . 

Теперв вб 1 видите, каких затрат времени и памити стоит создание потока, его 
поддержание в системе и завершение. Но на самом деле ситуацин егце хуже из-за 
необходимости переклтченил контекста (context switching). Компвготер с одним 
процессором может одновременно вмполннтб толбко что-то одно. Следователкно, 
операционнаи система должна распределлтБ физическии процессор между всеми 
своими потоками (логическими процессорами). 

В произволБНБш момент времени Windows передает процессору на исполнение 
один поток. Зтот поток исполннетсл в течение некоторого временного интервала, 
иногда назвшаемого тактом (quantum). После завершенгш зтого интервала кон- 
текст Windows переклгочаетси на другои поток. При зтом обнзателвно происходит 
следуготее: 

1. Значенгш регистров процессора исполннгогцегосн в даннвш момент потока со- 
храннготсл в структуре контекста, котораи располагаетсл в ндре потока. 

2. Из набора имегогцихсн потоков вБгделнетси тот, которому будет передано управ- 
ление. Если ввгбраннБш поток принадлежит другому процессу, Windows пере- 
клгочает длн процессора виртуалБное адресное пространство. Толбко после зтого 
возможно вБшолнение какого-либо кода или доступ к каким-либо даннБш. 

3. Значенгш из вБгбраннои структурБг контекста потока загружаготсл в регистрБг 
процессора. 

После переклгоченгш контекста процессор исполннет вБгбраннБпг поток, пока 
не истечет вБгделенное потоку времн, после зтого снова происходит переклгочение 
контекста. Windows делает зто примерно каждвге 30 мс. Никакого вБшгрБгша в про- 
изводителБности или потребленгш памлти переклгочение контекстов не дает. Оно 


1 Библиотеки длл C# и болћшинства других управллемнх лзвгков программировангш не 
имегот метода DllMain, позтому управлнемвге DLL -библиотеки не получагот уведомлении 
DLL THREAD ATTACH и DLL THREAD DETACH. Что же касаетсн неуправллемвгх 
библиотек, то при помшци Win32-^yHKirini DisableThreadLibraryCalls они могут отклгочатБ 
режим полученгш уведомлении. К сожаленшо, многие разработчики неуправллемого кода 
не исполвзугот зту функцшо просто потому, что не знагот о неи. 



728 Глава 26. Потоки исполненил 


требуетсн to.ti.ko дли того, чтобм операционнаи система бмла надежнои и бмстро 
реагировала на деиствин конечнмх полћзователеи. 

Если поток какого-то приложенгш зацикливаетсн, Windows его периодически 
вмгружает и передает процессору другои поток длл исполненгш. К примеру, зто 
может 6мтб поток диспетчера задач, позволнгогцего завершитБ процесс, в котором 
исполниетси зависшии в бесконечном цикле поток. Процесс в резулкгате прекра- 
гцает свого работу, тернп несохраненнме даннме, но осталБнме процессм в системе 
продолжагот функционироватБ, как ни в чем не бмвало. Полћзователго не прихо- 
дитсн перезагружатБ компккпср. Как видите, переклгочение контекстов приводит 
к повмшениго отказоустоичивости, хотл за зто приходитсн платитБ снижением 
производителћности. 

На самом деле издержки егце вмше, чем можно предположитБ. При переклгоче- 
нии контекста на другои поток производителБностБ серБезно падает. Пока работа 
ведетсл с одним потоком, его код и даннвге находитсн в кзше процессора, чтобвг 
обрагценгш процессора к оперативнои памнти, замедллгогцие работу, происходили 
реже. Однако новбги поток, скорее всего, исполннет совсем другои код и имеет 
доступ к другим даннвгм, которБгх егце нет в кзше процессора. Значит, прежде чем 
вернутБСн к прежнеи скорости работкг, процессор внгнужден некоторое времи об- 
рагцатБСн к оперативнои памнти, наполннн кзш. А примерно через 30 мс происходит 
очередное переклгоченгге контекста. 

Времн переклгочешш контекста зависит от архитектурвг процессора и его бвгстро- 
деиствин. А времн заполненин кзша зависит от запугценнвгх в системе приложении, 
размера самого icjnia и рнда других факторов. Позтому оценитв, с какими времен- 
нбгми затратами свнзано каждое переклгоченгге контекста, невозможно. Достаточ- 
но просто запомнитБ, что при разработке вБгсокопроизводителБНБгх приложении 
и компонентов переклгоченгш контекста нужно по возможности избегатв. 

ВНИМАНИЕ 

Если в конце временного промежутка Windows решает продолжитБ исполнениеуже 
исполнлемого потока (а не переходитБ к другому), переклнзченил контекста не про- 
исходит. Зто значителБно повмшает производителБностБ. 


ВНИМАНИЕ 

Поток может самопроизволБно уступитБ управление до завершенил такта, что про- 
исходит доволбно часто, например, если потокожидает ввода-вмвода (клавиатура, 
MbiLUb, фаил, ceTb и т. д.). Так, поток приложенил Notepad оби 1 чно ничего не делает, 
ожидал ввода даннмх. При нажатии полБЗОвателем клавиши Windows пробуждает 
зтот поток, чтобм тот обработал данное деиствие. Обработка занимает всего 5 мс, 
после чего вмзмваетсл Win32-^yHKpnn, сообидакидал Windows о готовности к об- 
работке следукхдего собмтил ввода. Если собмтил ввода отсутствукзт, поток пере- 
водитсл в состолние ожиданил (с отказом от оставшеисл части такта). В резулктате 
поток не будет планироватБСл на исполнение процессором до следукнцего собнтил 
ввода. Такои подход повмшает производителвности системм, потому что потоки, 
находл 1 диесл в состолнии ожиданил, не расходукзт попусту процессорное времл. 
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В ходе процедурм уборки мусора CLR приостанавливает все потоки, просма- 
тривает их стеки в поисках корнеи, помечает обЂектм в куче, снова просматривает 
стеки (обновлнн корни обвектов, перемегценнмх в процессе сжатин) и возобновлнет 
исполнение всех потоков. Таким образом, сокрапдение количества потоков повмсит 
производителБностБ уборки мусора. В процессе отладки Windows приостанавливает 
все потоки приложенип в каждои точке останова и снова запускает их при переходе 
к следугошему шагу или при запуске приложенин. Соответственно, чем болвше 
потоков, тем медленнее будет происходитв отладка. 

Из сказанного можно сделатБ заклгочение, что исполБЗОвангш потоков нужно 
по возможности избегатв, так как они потреблигот памнтБ и требугот времени длн 
своего создангш, управленгш и завершенгш. При переклгочении контекста и убор- 
ке мусора времн также тратитсл впустуго. С другои сторонБг, без потоков тоже не 
обоитисБ, так как именно они обеспечивагот в Windows приемлемвге показатели 
надежности и времени реакции. 

Не стоит забвшатБ и о том, что компБГОтер с несколБКими процессорами может 
исполнптБ несколБКО потоков одновременно, что улучшает масштабируемоств 
системБг (способностБ вБшолненгш болБшеи работБг за менБшее времп). Каждому 
ндру процессора назначаетсл свои поток, и зто ндро организует собственное пере- 
клгочение контекстов. Операционнап система следит за тем, чтобвг один поток не 
планировалсп одновременно на несколвких лдрах, так как зто привело 6бг к хаосу. 
В настонгцее времн повсеместно встречаготсн компБготервг с несколБКими процес- 
сорами или многондернБгми процессорами. Но на заре созданип Windows работатБ 
приходилосБ на машинах с одним процессором, и именно позтому длн повБгшенин 
надежности операционнои системБг 6бгли введенвг потокгг. В настонгцее времл потокгг 
позволпгот повбгситб производителБностБ на машинах с несколБКими ндрами. 

В оставшихсп главах зтои книги рассматриваготси механизмвг Windows и CLR, 
позволпгогцие зффективно ответитв на вопрос, как при минималвном количестве 
потоков сохранитБ работоспособностБ кода и каким образом масштабироватБ код 
дли исполненгш на машине с многондернБгм процессором. 


Так далБше не поидет! 

Если думатБ толбко о производителБности, оптималБное число потоков на машине 
должно 6бгтб равно числу установленнБгх на неи процессоров. То еств на компБготере 
с одним процессором должен работатБ всего один поток, на компвготере с двумл 
процессорами — два и т. д. ПричинБг очевиднБг: еслгг количество потоков преввгшает 
количество процессоров, начинаетсн переклгочение контекста, и производителБностБ 
падает. А при наличии одного потока на процессор контекстное переклгочение не 
требуетсл, и все потоки исполнпготсл на полнои скорости. 

Тем не менее при разработке Windows специалистБг Microsoft отдали предпо- 
чтение надежности и бнгстроте реакции на деиствгш полвзователл, а не скорости 
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расчетов и производителБности вбшолнсшш приложении. И с моеи точки зренин зто 
правилБно. Не думаго, что кто-либо полБЗОвалси 6bi Windows или .NET Framework, 
если 6 б 1 приложенин по-прежнему могли блокироватБ работу операционнои системБ1 
и других приложении. Именно позтому в Windows каждому процессу вБвделлетси 
собственнБпг поток, что повБпнает надежностБ системБ1 и бљклроту реакции. К при- 
меру, на рис. 26.1 показано окно диспетчера задач, открБтгое на вкладке Performance 
(ББ 1 Стродеиствие). 


File Optiors View 


Task Manager 


| Processes | Performance | App history | Stsrtup | Users | Details | Services | 
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2 
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Hyper-V support: 
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No 

128 KB 
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(p) Fevverdetails | (§) Open Resource Monitor 


Рис. 26.1 . Диспетчер задач c информациеи o производителБности системн 


Как видите, на момент полученгш снимка зкрана на моем компвготере 6бгло 
запугцено 55 процессов, а значит, по менвшеи мере 55 потоков. Ведв длн каждого 
процесса сугцествует хотн 6бг один поток. Однако как легко увидетк, потоков на са- 
мом деле 864! Все зти потоки ввгделнгот памнтБ, и зто при том, что ее полнбш обвем 
на моем комппготере составлнет 4 Гбаит. Что же касаетсл соотношенгш количества 
процессов и потоков, то в среднем на один процесс приходитсл 15,7 потока, тогда 
как в идеале на моем двухБидерном процессоре процесс должен состонтб всего из 
двух потоков. 

Более того, расположеннан в левом верхнем углу диаграмма загрузки процессора 
показвшает, что в настоигции момент загрузка составлнет всего 5 %. То еств 95 % 
времени зти 864 потока в буквалвном смпгсле ничего не делагот — они просто за- 
нимагот памлтБ, которан не исполБзуетсл, пока потоки не начинагот исполннтбсн. 
Резонно спроситБ, нужнБг ли приложенгшм все зти ничего не делагогцие потоки? 
Разумеетсл, нет. Чтобвг посмотретв, какои из процессов ивлиетси самвгм <<расто- 
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чителБнмм», переидите на вкладку Details (Подробнее), добавБте столбец Threads 
(Счетчик потоков) 1 и отсортируите его по убћшаншо, как показано на рис. 26.2. 


fjJ Task Manager 
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Рис. 26.2. ПроцессБ! в окне диспетчера задач 


Как видите, система создала 105 потоков, но исполБзует 1 % могцности про- 
цессора, приложение Explorer создало 47 потоков при 0 % нагрузке на процессор, 
приложение Microsoft Visual Studio (Devenv.exe) создало 36 потоков, опитб же ис- 
полБзун 0 % могцности процессора, та же самаи картина с приложением Outlook, 
создавшим 24 потока при 0 % и т. п. Что же происходит? 

ЗнакомисБ с Windows, разработчики узнагот, что создание процессов в зтои 
операционнои системе — дорогостошцаи процедура. Создание процесса занимает 
несколвко секунд, требует вБгделешш изридпого обвема памлти, зту памлтБ тре- 
буетсл инициализироватБ, нужно загрузитБ с диска ЕХЕ- и DLL -фаилБг и т. п. По 
сравненшо с зтим создатв поток достаточно просто. Позтому разработчики вместо 
процессов предпочитагот создаватв потоки, множество которвгх mbi и видим перед 
собои. Но в сравнении с болвшинством других системнБ 1 Х ресурсов создание по- 
тока — не такал уж дешевал процедура. И применнтв их следует осмотрителБно 
и толбко там, где они деиствителБно уместнБг 

Как видите, упомннутвш приложенгш исполБзугот потоки не зффективно. Не- 
понитно, зачем зти потоки вообгце сугцествугот в системе. Одно дело — вБвделитБ 


1 Длл зтого гцелкните правои кнопкои ммши на сушествукицем столбце и вмберите команду 
Select Columns (Ввгбратв столбцм). 



732 Глава 26. Потоки исполненил 


ресурсм дли приложенил, и совсем другое — вБвделитБ их и не исполБЗОватБ. ВедБ 
вБвделение памнти под стеки потоков означает, что ее останетсл менвше дли более 
важнБ1х даннБ1Х, например документов полвзователн 1 . 

А теперв представБте, что процесс запушен в сеансе удаленного рабочего стола 
одного полБЗОватели, но у машинБ 1 на самом деле 100 полБЗОвателеи. То еств запу- 
скаетсн 100 зкземплнров приложенин Outlook, каждвш из которБ 1 х создает 24 ничего 
не делагогцих потока. Мбг получаем 2400 потоков, каждвги с собственнБши ндром, 
ТЕВ, стеком режима полБЗОвателн, стеком режима ндра и т. п. Огромное количество 
впустуго потраченшлх ресурсов. Зту практику пора прекрагцатв, особенно если 
Microsoft хочет, чтобнг полБЗОватели успешно работали с Windows на нетбуках, 
на болБшинстве которвгх всего 1 Гбит оперативнои памнти. Именно практике зф- 
фективного проектировангш приложенгш с минималБНБш количеством потоков 
и посвигценБ! последние главБг зтои книги. 


Тенденции развитил процессоров 

В прошлом имел место постонннбнг рост бБгстродеиствгш процессоров, в резулвтате 
даже медленно работагогцие приложенгш при переходе на более новуго машину 
начинали работатв бБгстрее. Однако бесконечно нарагциватБ бБгстродеиствие не- 
возможно. Кроме того, процессор, работагогции с болвшои скоростБГО, вБгделлет 
тепло, которое нужно рассеиватБ. НесколБКО лет назад н приобрел компкготер новои 
модели от уважаемого производителл. Однако из-за дефекта прошивки скороств 
врагценгш вентиллтора оказаласв недостаточнои; и через некоторое времн процессор 
и материнскан плата просто расплавилисБ. ПроизводителБ заменил мне компБготер 
и «улучшил» прошивку, просто заставив вентшштор врагцатвсн бБгстрее. Но из-за 
зтого стали намного бнгстрее садитБСн батареики, всдб вентилнтор потреблнл много 
знергии. 

С подобнБши проблемами в наши дни приходитсн сталкиватБСи всем произ- 
водителнм аппаратного обеспеченгш. Из-за отсутствин возможности бесконечно 
нарагциватБ скоростБ процессоров, они пвгтаготсн уменБшитБ транзисторБг, что6бг 
на однои микросхеме можно 6бшо разместитБ их болБше. Уже сугцествугот кремни- 
еввге микросхемБг, содержагцие два и более процессорнвгх идра. А значит, скоростн 
функционировангш программного обеспеченгш повбгситсл толбко при условии, 


1 ХотелосБ бш егце раз продемонстрнроватћ, насколБко удручагоше обстолт дела. Откроите 
приложение Notepad.exe и посмотрите с помотцбго Диспетчера задач количество свлзаннвгх 
с ним потоков. Вшберите в менго File (Фаил) приложенил команду Open (Открбгтб), и как 
толвко откроетсл диалоговое окно File Open (ОткрБгтие фаила), посмотрите на количество 
новбгх потоков. Fla моеи машине резулвтатом открБгогн зтого окна стало создание 31 допол- 
нителБного потока! Аналогично обстолт дела с лго6бш другим приложением, открБшагоиџш 
диалоговое окно открвгош или сохраненил фаила. И болвшинство зтих потоков не завер- 
шаетсл даже после закрвгош окна! 
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что оно умеет работатћ с несколћкими ндрами. Как зтого до6итбсн? Разумно ис- 

полБзул потоки. 

В настолгцее времи сугцествугот три вида многопроцессорнБ 1 х технологии: 

□ Многопроцессорнме решенин. НекоторБге компБГОтерБ 1 просто оснашагот не- 
сколбкими процессорами. Другими словами, на материнскои плате паходмтсм 
несколвко гнезд, в каждом из которБ 1 х располагаетсл процессор. Зто приводит 
к увеличениго размеров материнскои платБ 1 , а значит, и корпуса. В некоторнгх 
случалх приходитсл ставитн также дополнителБНБ1е источники питании из-за 
повБшенного потребленин знергии. Такие компБГОтерБ1 исполБЗОвалисБ в течение 
несколвких деслтилетии, но постепенно их популирностБ сходит на нет из-за 
6олбшого размера и вбгсокои стоимости. 

□ ГиперпотоковБ 1 е микросхемм. Зта технологин (от Intel) позволлет однои 
микросхеме функционироватв как две. Микросхема содержит два набора архи- 
тектурнБ1х состолнии, таких как регистрБ1 процессора, при зтом имсстсм всего 
один набор механизмов исполненгш. Длн Windows зто вмглндит как наличие 
в машине двух процессоров, и операционнан система одновременно планирует 
поведение двух потоков, однако исполннетсн толбко один из них. Как толбко он 
прерБшаетсн из-за недостатка размера кзша, ошибочного прогнозировангш ветви 
или зависимости по даннвш, микросхема переклгочаетсл на другои поток. Все 
зто происходит на аппаратном уровне, и Windows об зтом не «знает». С точки 
зренгш операционнои системм оба потока вмполннготсн одновременно. При на- 
личии на однои машине несколвких гиперпотоковБ1х процессоров операционнан 
система сначала назначит по одному потоку на каждвш процессор, в резулвтате 
чего они деиствителБно будут вбшолннтбсн одновременно. Все же осталвнвге 
потоки будут распределитБСи по уже занптБш процессорам. По утвержденгшм 
Intel, такои подход повмшает производителвностБ на 10-30 %. 

□ Многондернме микросхемм. Несколнко лет назад попвилисб микросхемБц со- 
держагцие более одного процессорного идра. На момент написангш зтои книги 
6бши доступнБ 1 микросхемБ 1 с двумн, тремн и четвфБмн ндрами. Два идра имеет 
даже процессор моего ноутбука. Л уверен, что зта технологгш скоро распростра- 
нитсн даже на мобилвнБШ телефонБг Компангш Intel работала даже над про- 
тотипом процессора с 80 идрами. Представлнете, насколвко могцнбш нвлиетси 
такои компвготер! Кроме того, в Intel имеготсл гиперпотоковме микросхемм 
с несколвкими ндрами. 


CLR- и Windows-noTOKH 

В настолгцее времл CLR исполвзует способностБ Windows работатп с потоками, 
позтому частБ V даннои книги посвпгцена рассмотрениго возможностеи, которвш 
открвшаготсн перед разработчиками, создагогцими код с помогцбго CLR. Мб 1 погово- 
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рим о том, как исполниЈОтсн потоки в Windows и как на их поведение влинет CLR. 
Длл полученин дополнителБнои информации о потоках исполненин рекомендуго 
мои предмдушие книги, в частности пнтое издание Windows via С/С++ (Microsoft 
Press, 2007). 

Ha первв 1 х порах сугцествованил .NET Framework проектировгцики CLR 
решили, что среда CLR должна поддерживатБ логические потоки, которБ 1 е не 
обизанБ 1 однозначно соответствоватв потокам Windows. В 2005 году группа CLR 
отказаласБ от зтои идеи, так что в настоигцее времи CLR -потоки аналогичнБ 1 
Windows-noTOKaM, однако в .NET Framework встречаготси отделвнвт пережитки 
прежних попБ 1 ток. Например, класс System. Environment предоставлиет своиство 
CurrentManagedThreadld, которое возвравдает CLR -идентификатор потока, тогда 
как класс System . Diagnostics . ProcessThread предоставлнет своиство Id дли по- 
лученгш Windows-H^eHTH^iiKaTopa того же потока. МетодБ 1 BeginThreadAffinity 
и EndThreadAff inity класса System. Thread также 6бши введенБ 1 в предположении 
о том, что CLR -поток может не совпадатв с Windows-noTOKOM. 

Дли приложении Windows Store компанил Microsoft исклгочила некоторБШ 
функции API, относнвдиесл к потокам, потому что зти функции приводили к нежела- 
телБнвш последствинм (см. раздел «Так далвше не поидет!» зтои главБ 1 ) или не спо- 
собствовали достижениго целеи, поставленнБ 1 х Microsoft дли приложении Windows 
Apps. Например, класс System . Thread недоступен длн приложении Windows Store 
из-занежелателБшлх функции API (таких, KaKStart, IsBackground, Sleep, Suspend, 
Resume, loin, Interrupt, Abort, BeginThreadAffinity и EndThreadAffinity). Лично 
a считаго, что зто сделано правилБно, хоти и позже, чем следовало 6i>i. Соответствен- 
но в главах 26-30 будут рассматриватвсн некоторБге функции APIs и возможности, 
доступнБШ длн настолБНБ 1 х приложении, но не длн приложении Windows Store. Во 
времи чтешш зтих глав bbi бвштро поимете, почему некоторввд функции API недо- 
ступнв! длл приложении Windows Store. 


Потоки длл acHHxpOHHbix 
вв1числителБНБ1х операции 

В зтом разделе а покажу, как создатв поток и заставитк его исполнитб асинхроннуго 
ББ1числителБнуго операциго. При зтом а не рекомендуго полБЗОватксл приемами, 
описБ 1 ваемБ 1 ми в зтом разделе (а длн приложении Windows Store они и вовсе не- 
возможнб 1 из-за недоступности класса System . Thread). По возможности длл зтои 
цели лучше прибегатв к доступному в CLR пулу потоков (thread pool). О нем mbi 
поговорим в следуговдеи главе. 

Возможнб 1 ситуации, когда требуетси нвно создатв поток длл вБшолненгш кон- 
кретнои ББ1числителБнои операции. 06 бшно такаи необходимостк возникает при 
вБшолнении кода, приводнвдего поток в состонние, отличное от обвшного состоннин 
потока из пула. К примеру: 
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□ Поток требуетсл запуститБ с нестандартншм приоритетом (все потоки пула 
ппшо.тпи iotcm с обмчнмм приоритетом). Хотн изменитБ приоритет можно, но 
делатБ зто не рекомендуетсл, кроме того, изменение приоритета не сохраннетсл 
между операцинми с пулом потоков. 

□ Чтобм приложение не закрмлосв до завершенгш потоком заданин, требуетсл, 
чтобм поток исполннлсл в фоновом режиме. Зта тема подробно рассмотрена 
в разделе <<Фоновме и активнме потоки» далее в зтои главе. Потоки из пула 
всегда нвлнјотсн фоновмми, и сугцествует риск, что они не успегот вмполнитб 
задание из-за того, что CLR решит завершитБ процесс. 

□ Задангш, спизги m i>i о с вБ 1 числешшми, о6б1чно вбшолниготсл краине долго; длл 
подобнБ1х задании л не стал 6hi отдаватБ решение о необходимости создангш 
нового потока на откуп логике пула потоков. 

□ Возможно возникнет необходимоств преждевременно завершитв исполниго- 
гциисн поток методом Abort класса Thread, которкш 6бш подробно рассмотрен 
в главе 22. 

Длн создангш ввгделенного потока вам потребуетсл зкземплнр класса System. 
Threading . Thread, длн полученгш которого следует передатв конструктору имн 
метода. Вот прототип такого конструктора: 

public sealed class Thread : CriticalFinalizerObject, ... { 
public Thread(ParameterizedThreadStart start); 

// Здеси не показанм редко исполБзуемуе конструкторт 

} 

Параметр start задает метод, которкги будет вбшолнитбсн в ввгделен- 
ном потоке. Сигнатура зтого метода должна совпадатк с сигнатурои делегата 

ParameterizedThreadStart: 1 

delegate void ParameterizedThreadStart(Object obj); 

Создание обвекта Thread нвлнетсл достаточно простои операциеи, так как при 
зтом физическии поток в операционнои системе не поивлиетсл. Длл создангш 
физического потока, призванного иснолнитб метод обратного вБгзова, следует 
восполБЗОватБСи методом Start класса Thread, передав в него обвект (состонние), 
которвпг вб1 хотите сделатБ аргументом метода обратного вБгзова. Следугогции код 
демонстрирует процедуру создангш ввгделенного потока, которкш затем асинхронно 
вБгзБгвает метод: 


1 Класс Т hread также предлагает конструктор, принимакнции делегат Т hread Start, которми 
не имеет аргументов и не возврагцает значении. Но лично ц не рекомендуго их исполБзоватБ 
из-за многочисленннх ограничении. Если метод вашего потока принимает класс Object и 
возврагцает значение типа void, внзовите его при помохци ввгделенного потока или пула 
потока, как показано в главе 27. 
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using System; 

using System.Threading; 

public static class Program { 
public static void Main() { 

Console.WriteLine("Main thread: starting a dedicated thread " + 

"to do an asynchronous operation"); 

Thread dedicatedThread = new Thread(ComputeBoundOp); 
dedicatedThread.Start(5); 

Console.WriteLine("Main thread: Doing other work here..."); 

Thread.Sleep(10000); // Имитацил другои работн (10 секунд) 

dedicatedThread . loin( ); // Ожидание завершенил потока 
Console.WriteLine("Hit <Enter> to end this program..."); 

Console.ReadLine(); 

} 

// Сигнатура метода должна совпадатн 

// с сигнатурои делегата ParameterizedThreadStart 

private static void ComputeBoundOp(Object state) { 

// МетодЈ вшполнлемми внделенннм потоком 

Console.WriteLine("In ComputeBoundOp: state={0}", state); 

Thread.Sleep(10@0); // Имитацил другои работн (1 секунда) 

// После возврашенил методом управленил вмделеннии поток завершаетсл 

} 

} 

Резулетат компилнции и запуска такого кода: 

Main thread: starting а dedicated thread to do an asynchronous operation 
Main thread: Doing other work here... 

In ComputeBoundOp: state=5 

Так как mbi не можем контролироватБ очередноств исполненин потоков 
в Windows, возможен и другои резулћтат: 

Main thread: starting а dedicated thread to do an asynchronous operation 

In ComputeBoundOp: state=5 

Main thread: Doing other work here... 

ЗаметБте, что метод Main вБИБшает метод ioin. Последнии заставллет вБ 13 Б 1 ва- 
клции поток остановитБ вБшолнение лкзбого кода до момента, пока поток, опреде- 
леннБш при помогци dedicatedThread, не завершитсл сам или не будет завершен. 


ПрИЧИНБ! ИСПОЛБЗОВанИЧ потоков 

Потоки ИСПОЛБЗуГОТСИ ПО двум ОСНОВНБ1М причинам: 

□ Улучшение времени отклика (обмчно дли клиентских приложении с графи- 
ческим интерфеисом). Windows вБвделнет каждому приложениго отделкнБш 



Причинм исполБЗОваниа потоков 737 


поток, чтобм зацикливание одного приложенин не мешало работе других. Ана- 
логичнмм образом в клиентских приложениих с графическим интерфеисом 
можно вБвделитБ частБ работм в отделБнми поток, чтобм интерфеис продолжал 
реагироватБ на деиствгш полБЗОвателл. Вероитно, в зтом случае количество по- 
токов превБ1Сит количество ндер, что обернетсл лишними затратами системнБ1х 
ресурсов и снижением производителБности. С другои сторонБр полБЗОвателБСКии 
интерфеис бнгстрее реагирует на деиствгш полвзователн, улучшан его впечатле- 
нгш от работвг с приложением. 

□ ПроизводителћностБ (дли клиентских и сервернћгх приложении). Так как 

система Windows может планироватБ по одному потоку на процессор, а про- 
цессорБг могут исполшгтб потоки одновременно, параллелвное вБгполнение 
несколБКих операцтш улучшит производителБностБ приложенгш. Конечно, 
улучшение достигаетсл толбко в том случае, если приложение ввшолниетсл 
на машине с несколБКими процессорами. Впрочем, такие компБготерБг в наше 
времн уже достаточно распространенвг. ВопросБг создангш приложении, предна- 
значеннБгх длл работБг в многопроцессорнои конфигурации, рассматриваготсл 
в главах 27 и 28. 

А теперв м хотел 6бг поделитБСн с вами своеи теориеи. Итак, каждвги компбго- 
тер снабжен таким могцнбгм инструментом, как процессор. И если вбг покупаете 
компБготер, он должен работатн все времн. Другими словами, и считаго, что все 
процессорвг в машине должнбг исполБЗОватБСл на 100 %. Впрочем, тут нужно 
сделатБ две оговорки. Во-перввгх, при питании от аккумулнтора 100-процентное 
исполБЗОвание процессора сократит времл работвг с машинои. Во-вторнгх, в не- 
которвгх центрах обработки даннвгх предпочитагот иметБ деслтБ компБготеров с 
процессорами, работагогцими на половиннои могцности, вместо пнти, процессо- 
рвг которвгх загруженБг на 100 %. Дело в том, что полностбго загружешшш про- 
цессор вБгделлет тепло, а значит, требует системБг охлажденгш. Однако питание 
такои системБг может оказатБсн более затратнБгм делом, чем питание болншего 
количества компвготеров, работагогцих на менвшеи могцности. Впрочем, наличие 
6олбшого количества компвготеров тоже значителвно повнгшает издержки, ведк 
каждБш из них требует периодического обновленгш аппаратного и программного 
обеспеченгш. 

Теперв, если вбг согласнБг с моеи теориеи, нужно определитБСн с тем, какие за- 
дачи должен решатк процессор. Но сначала — неболБшое вступление. В прошлом 
как разработчики, так и конечнвге полБЗОватели считали, что могцностб компбго- 
теров недостаточна. И позтому код не вбшолннлси, пока конечнБги полБЗОвателБ 
не давал на зто разрешенгш при помогци таких злементов интерфеиса, как пунктвг 
менго, кнопки и флажки, тем самнгм нвно показвгваи, что согласен предоставитв 
приложениго необходимБге ресурсБг процессора. 

Сеичас все изменилосБ. СовременнБге компБготерБг достаточно могцнбг и в бли- 
жаишем будугцем могут статв егце более могцнбши. Как л уже упоминал в зтои 
главе, часто в окне Диспетчера задач можно видетв, что процессор занит 5 % вре- 
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мени. Если бм ндер бмло не два, а четмре, такал ситуацин возникала бм eme чаше. 
Когда поивитсл 80-ндернми процессор, вообгце получитсл, что практически все 
времн компБШтер ничего не делает. С точки зренгш потребители получаетсл, что 
за болБшие денБги машина вмполниет менБше работм! 

Именно позтому производители аппаратного обеспеченгш с трудом продагот 
полБЗОвателлм многондернме компБГОтерм. Программное обеспечение не может 
полноценно исполБЗОватБ предоставлнемме возможности, а значит, полБЗОвателБ 
не получает вбггодбг от покупки машинБг с дополнителБНБш процессором. То естБ 
в настонгцее времи мбг имеем из6бгток компБГОтернБгх могцностеи, позтому разра- 
ботчики могут себе позволитб их активное потребление. РанБше даже помбгслитб 
6бшо i [С.1Р).зз о том, что6б1 приложение занималосБ дополнителБНБши вБгчисленгш- 
ми, если не 6бшо полнои уверенности, что конечному полБЗОвателго понадобитси 
резулБтат зтих ВБГчислении. Но теперБ, при наличии дополнителБНБгх могцностеи, 
зто стало ВОЗМОЖНБ1М. 

Например, по завершении набора текста в редакторе Visual Studio зто прило- 
жение автоматически вБ13Б1вает компилитор и обрабатБшает введеннБш код. Такои 
подход повБгшает продуктивностБ труда разработчиков, так как они сразу видлт 
ошибки вводимого кода и немедленно могут их исправитБ. Фактически в настонгцее 
времи из последователБности редактирование-построение-отладка пропал цен- 
тралБНБш член, так как построение (компилнцин) кода осугцествллетсн непрерБшно. 
КонечнБге полБЗОватели зтого даже не замечагот благодарн могцному процессору. 
ВедБ частБги запуск компилитора никак не отражаетсл на решении других задач. 
Л думаго, что в будугцих версинх Visual Studio из менго исчезнет пункт Build, так 
как компилнцгш станет полностбго автоматическои. Не толбко упрогцаетсл полбзо- 
вателБСКии интерфеис, но и само приложение дает «ответБ1» на нуждБг конечного 
полБЗОвателл, повБгшан продуктивностБ его работБг. 

С исклгочением отделБНБгх пунктов менго полБЗОватБСл приложением становитсл 
прогце. Остаетсн менБше вариантов и менБше концепции, которБге следует прочитатБ 
и запомнитБ. Именно многондернаи конфигурацгш позволлет упроститБ полБЗОва- 
ние компБготером настолБКО, что в один прекраснБш денв с ним сможет работатБ 
даже мои бабушка. Дли разработчиков удаление злементов полБЗОвателБСКОго ин- 
терфеиса означает менБшии обвем тестировангш и упрогцение основбг кода. Кроме 
того, ослабллетсл острота проблемБг локализации интерфеиса и сопроводителБнои 
документацгш. Все зто дает возможностб зкономитб времл и денБги. 

Вот егце несколБКО примеров активного потребленгш ресурсов процессора: 
проверка орфографии и грамматики в документах, пересчет злектроннБгх таблиц, 
индексирование фаилов на диске длн ускоренгш процедурБг поиска и дефрагмен- 
тацин жесткого диска длл повБгшенгш производителБности ввода-вБшода. 

Мне нравитси мир, в котором полБЗОвателБСКие интерфеисБг минимизируготсн 
и упрогцаготсл, оставлнн болБше места длл визуализацгш даннБгх, а приложенгш 
сами предлагагот информациго, помогагогцуго бнлстро решатБ насугцнБге задачи. 
Пришло времл творчески исполБЗОватБ программное обеспечение. 
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Планирование и приоритетм потоков 


Операционнвш системм с вмтесннгошеи многозадачноствго должнв 1 исполћзо- 
ватБ некии алгоритм, определнгошии порндок и продолжителБностБ исполненин 
потоков. В зтом разделе рассмотрен алгоритм, применнемми в Windows. И уже 
упоминал о наличии в каждом лдре потока контекстнои структурм, отражагошеи 
состоиние регистров процессора потока во времп его исполненин. После каждого 
такта Windows просматривает все сушествугопдие ндра потоков в поисках потоков, 
которме не находнтсл в режиме ожиданин, вмбирает один из них и переклгочаетсл 
на его контекст. При зтом фнксируетсн, сколбко раз каждми из потоков потребовал 
переклгоченин контекста. Зту информациго можно увидетБ в показанном на рис. 26.3 
окне приложенин Microsoft Spy++, в котором вмводлтсл своиства всех потоков. 
Обратите внимание, что вмбраннми поток запускалсп 31 768 раз 1 . 

Итак, каждми поток исполнпет код и манипулирует даннмми в адресном про- 
странстве процесса. Через такт Windows переклгочает контекст. Переклгоченип 
контекста продолжаготсл с момента загрузки операционнои системм и до завер- 
шенин ее работм. 

Windows назмвагот многопоточнои операционнои системои с вмтесннгошеи 
многозадачностБГО, потому что каждми поток может 6мтб остановлен в произволш 
нми момент времени и вместо него вмбран длн исполнешш другои. Как вм увидите, 
отим процессом в какои-то степени можно управлнтБ, но нелБЗи гарантироватБ, что 
поток будет исполннтбсн постоннно без прерћшашш другими потоками. 


♦ > l I« Ч—» ио _1.1*1«! 



Рис. 26.3. Своиства потоков в приложении Spy++ 


1 Можно также заметитБ, что поток находилсл в системе более 25 часов, но исполвзовалсл 
менее чем одну секунду процессорного времени. То естБ речБ идет о непродуктивном рас- 
ходовании ресурсов. 
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ПРИМЕЧАНИЕ 

Разработчики часто задакзт вопрос: каким образом можно гарантированно запустиљ 
поток через определенное времл после какого-то собмтип? Например, как запустиљ 
определеннми поток через 1 мс после прохожденил данннх через последователг.нв 1 и 
порт? R отвечакз просто: зто невозможно. 

Такие веш,и возможнм в onepau,noHHbix системах реалиного времени, но VVindovvs 
к ним не относитсл. Операционнме системи! реалиного времени требукзт доско- 
налиного знанич оборудованил, на базе которого они работакзт. То ести вам должнм 
6biTb известнм задержки контроллеров жесткого диска, клавиатурм и других ком- 
понентов. nnaT^opMaWindows создаваласв в Microsoft длп работн с саммм pa3HbiM 
annapaTHbiM обеспечением: различнмми процессорами, драиверами, сетлми и т. п. 
Именно позтому она не пвллетсл операционнои системои реалиного времени. 
Следует добавити, что из-за CLR управлпемми код еш,е хуже приспособлен длл ра- 
6oTbi в реалвном времени. Причин зтому много, втом числе динамическап загрузка 
библиотек, Ј1Т-компилпцил кода и уборка мусора, начало вмполненип которои не- 
возможно спрогнозироваљ. 


Каждому потоку назначаетси уровенБ приоритета с нулевого (самого низкого) 
до 31 (самого вмсокого). При вмборе потока, которми будет передан процессору, 
сначала рассматриваготси потоки с саммм вмсоким приоритетом и ставлтсн в оче- 
редћ в цикле. При обнаружении потока с приоритетом 31 он передаетси процессору. 
После завершении такта игцетсл следугогции поток с аналогичнмм приоритетом, 
чтобм переклгочитБ на него контекст. 

При наличии в очереди потоков с приоритетом 31 система никогда не передаст 
процессору поток с менвшим приоритетом. Зто условие назмваетси зависанием 
(starvation), а возникает оно в случае, когда потоки с вмсоким приоритетом по- 
треблигот практически все времн процессора и не дагот исполннтбсп потокам более 
низкого приоритета. Зависание намного реже возникает на машинах с многопро- 
цессорнои конфигурациеи, на котормх потоки с приоритетами 31 и 30 могут ис- 
полнитбсн одновременно. Система всегда стараетсл загрузитћ процессор, позтому 
он простаивает толбко при отсутствии готовмх к исполнениго потоков. 

Потоки с вмсоким приоритетом всегда исполннготси перед потоками с низким 
приоритетом вне зависимости от того, какие задангш вмполнпгот последние. Если 
в системе работает поток с приоритетом 5 и система определнет, что поток с более 
вмсоким приоритетом готов к работе, исполнение немедленно приостанавли- 
ваетси (даже если поток находитси в середине такта) и процессору передаетси 
новми поток. 

В процессе загрузки система создает поток обнуленин страниц (zero page thread), 
которому назначаетсн нулевои приоритет. Зто единственнБш поток в системе с та- 
ким приоритетом. Его задача состоит в обнулении свободнмх страниц и исполннетсн 
он толбко при отсутствии других потоков. 

llcnoc дело, что с точки зрешш разработчика сложно придуматБ рационалБное 
обЂнснение назначениго потокам приоритетов. Почему одному потоку присвоен 
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приоритет 10, а другому — 23? Длн решенип зтого вопроса Windows вводит аб- 
страктнуго «прослоику» над уровнем приоритетов. 

При разработке приложенин следует решитБ, должно ли оно реагироватБ бмстрее 
или медленнее, чем другие запугценнме на зтои же машине приложенин. В соот- 
ветствии с зтим решением вмбираетсн класс приоритета дли процесса. В Windows 
поддерживаготси шестБ классов приоритетов: Idle (холостого хода), Below Normal 
(ниже обмчного), Normal (обмчнми), Above Normal (вмше обмчного), High (вмсо- 
кии) и Realtime (реалБного времени). По умолчаншо вмбираетсн приоритет Normal, 
он же нвлиетси саммм распространеннмм. 

Приоритет холостого хода подходит длл приложении, которме запускаготси 
в системе, где бо./њше ничего не происходит (зто такие приложенин, как хранители 
зкрана). Даже не исполћзуемми в интерактивном режиме компвготер может 6 мтб 
занит (к примеру, функционирун как фаиловми сервер) и не должен конкурироватБ 
за процессорное времн с хранителем зкрана. Приложенин длл сбора статистики, 
периодически обновлнгогцие некоторое состонние, обмчно тоже не должнм стано- 
витбси преплтствием дли более важнћгх задании. 

Вбгсокии приоритет следует исполБЗОватБ толбко там, где зто деиствителБно не- 
обходимо. А приоритета реалБного времени вообгце лучше по возможности избегатв. 
Его вБгбор может помешатБ вБшолнениго таких системнкгх задании, как дисковбш 
ввод-вбшод или передача даннвгх по сети. Поток с приоритетом реалкного времени 
может помешатв обработке даннкгх, вводимбгх с клавиатурБг или при помогци мбшш, 
создаван у полвзователн впечатление, что система перестала работатв. По болБшому 
счету длн вБгбора такого приоритета нужно иметБ веские основангш, например не- 
обходимоств с минималБнои задержкои отвечатк на собнгтин аппаратного уровнн 
или вБшолнитБ какие-то кратковременнБге заданин. 

ПРИМЕЧАНИЕ 

Что6б 1 система работала без сбоев, процесс невозможно запустити с приоритетом 
реалБного времени при отсутствии прав на увеличение приоритета вмполненил. 
Зта привилегип по умолчаникз имеетсл толбко у администраторов и полБЗОвателеи 
с расширеннБ1ми правами. 


ВБгбрав класс приоритета, не нужно думатв о том, как ваше приложение соотно- 
ситсн со всеми осталБнвши приложенинми, достаточно сосредоточитБСн на потоках 
своего приложенгш. В Windows поддерживаготси семв относителБНБгх приоритетов 
потоков: Idle (холостого хода), Lowest (самвш низкгш), Below Normal (ииже о 6 бгч- 
ного), Normal (о 6 б 1 чнбги), Above Normal (вБшге обБшного), Highest (самБги вбгсокии) 
и Time-Critical (требугогции немедленнои обработки). Зти приоритетБг соотно- 
снтси с классамгг прггоритетов процесса. По умолчанггго длл потоков исполвзуетсн 
о 6 бгчнбги приоритет, соответственно, он применнетси чагце всего. 

Подводл итог, скажем, что процесс нвлиетсл членом класса приоритета и внутри 
него потокам назначаготси свнзаннвге друг с другом прггорггтетБг. Еслгг вбг заметггли, 
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'А ничего не говорил об уровннх приоритета с нулевого по 31. Разработчики при- 
ложении никогда не имегот с ними дела напрнмуго. За них зто делает система. 
Соотношение между классом приоритета процесса, относителћнмм приоритетом 
потока и итоговмм уровнем приоритета иллгострирует табл. 26.1. 


Таблица 26.1. Определение уровнн приоритета на основе класса приоритета 
процесса и относителвного приоритета потока 


ОтносителБнми 
приоритет потока 

Класс приоритета процесса 

Idle 

Below 

Normal 

Normal 

Above 

Normal 

High 

Realtime 

Time-Critical 

15 

15 

15 

15 

15 

31 

Highest 

6 

8 

10 

12 

15 

26 

Above Normal 

5 

7 

9 

11 

14 

25 

Normal 

4 

6 

8 

10 

13 

24 

Below Normal 

3 

5 

7 

9 

12 

23 

Lowest 

2 

4 

6 

8 

11 

22 

Idle 

1 

1 

1 

1 

1 

16 


К примеру, если поток с приоритетом Normal принадлежит процессу с приори- 
тетом Normal, ему назначаетси уровенћ приоритета 8. Так как приоритет Normal по 
умолчаниго исполБзуетси как длн классов, так и дли потоков, болБшинство потоков 
в системе имегот уровенБ приоритета 8. 

Длн потока с приоритетом Normal в вмсокоприоритетном процессе уровенв 
приоритета равен 13. Если поменнтБ класс приоритета на Idle, уровенБ приори- 
тета потока снизитси до 4. Помните, что приоритетм потоков свизанм с классом 
приоритета процесса. При изменении последнего относителБнми приоритет потока 
остаетси без изменении, а вот уровенБ приоритета меннетсл. 

Обратите внимание: в таблице нет комбинации, при которои поток получает 
нулевои уровенБ приоритета. Как уже упоминалосћ, зтот приоритет зарезервирован 
дли потока обнуленин страниц, позтому система не позволнет присвоитћ его какому- 
то другому потоку. Недоступнм также следугогцие уровни приоритета: 17, 18, 19, 
20, 21, 27, 28, 29 и 30. Они зарезервированм под драиверм устроиств, работаклцие 
в режиме идра, а потому не присваиваготси полвзователБСКим приложешгам. Об- 
ратите внимание, что поток в классе приоритета Realtime не может иметБ уровенБ 
приоритета ниже 16. В то же времл потоки в осталвнвгх классах приоритета не могут 
получитБ уровенБ вБпне 15. 

















Планирование и приоритети потоков 743 


ПРИМЕЧАНИЕ 

Концепцил классов приоритета процесса может навести на Mbicnb, что Windows 
каким-то образом управллет очередноствк) процессов. Но очередности операцион- 
нал система определлет толико дпл потоков. Класс приоритета процесса лвллетсл 
абстрактнмм понлтием, помогакзидим логически сопоставити относителвнукз важности 
одного запу|денного приложенил с осталинмми; никаких других функции у него нет. 


ВНИМАНИЕ 

Лучше снизиљ приоритет одного потока, чем повмситв приоритет другого. Обимно 
понижение приоритета требуетсл, если поток вмполнлет длителинме ввмисленил, 
например компилирует код, проверлет орфографикз, пересчитнвает злектроннне 
таблицм и т. п. rioBbiLuaTb приоритет имеетсммсл, если потокдолжен бмстро отреа- 
гировати на какое-то собмтие, запуститвсл на короткии промежуток времени и вер- 
HyTbcn в состолние ожиданил. Потоки с вмсоким приоритетом болишук) части своего 
суидествованил находлтсл в режиме ожиданил, не влилл на бнстродеиствие всеи 
системм. В качестве примера потока с вмсоким приоритетом можно упомлнутв поток 
Проводника Windows (Windows Explorer), отслеживакнции нажатие клавиши Windows 
полизователем. Проводник приостанавливает потоки с более низким приоритетом 
и немедленно вмводит на зкран менкз. В процессе навигации поток Проводника 
Windows бмстро отвечаетна нажатил кпавиш, обновллет менкз и приостанавливаетсл 
до следукош,его нажатил клавиши полизователем. 


Обмчно процесс получает класс приоритета в зависимости от того, каким про- 
цессом он бмл запугцен. Болвшинство процессов инициируготсл Проводником 
Windows, присваивагогцим всем своим потомкам класс приоритета Normal. Управ- 
лиемме приложенин не могут владетБ своими процессами, они запускаготсл в домене. 
Именно позтому они не могут менитћ класс приоритета процесса, ведБ зто окажет 
влилние на весБ запугценнми в процессе код. К примеру, многие приложении ASP. 
NET вмполннготсн в одном процессе, хотл каждое из них работает в собственном 
домене приложении. То же самое можно сказатБ о приложениих Silverlight, запу- 
скаемБгх в процессе интернет-браузера, или управлнемћгх хранимћгх процедурах, 
запускаемћгх внутри процесса Microsoft SQL Server. 

В то же времи приложение может мендтв относителБНБш приоритет своих 
потоков при помогци своиства Priority класса Thread, которому присваиваетси 
одно из пити значении (Lowest, BelowNormal, Normal, AboveNormal или Highest), 
определеннвгх в перечислении ThreadPriority. При зтом точно так же, как 
Windows резервирует длн себн нулевои уровенв и уровенБ реалБного времени, CLR 
резервирует уровни приоритета Idle и Time-Critical. В настоншее времн в CLR 
отсутствугот потоки с уровнем приоритета Idle, но в будугцем ситуацгш может по- 
меннтБСн. При зтом поток финализации, о котором шла речк в главе 21, исполнлетсн 
науровнеприоритета Time-Critical. Соответственно, разработчикам управлнемвгх 
приложении остаготсл пнтб приоритетов потока: в табл. 26.1 зто строки со второи 
(Highest) по шестуго (Lowest). 
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ВНИМАНИЕ 

В настолш,ее времл редко встречакггсл приложенин, исполвзукзш,ие приорите™ по- 
токов. Тем не менее хотелоси 6 bi наделтвсл, что в будуидем, когда процессорн будут 
загружени на 100 %, HenpepbiBHO вб1полнчп полезнукз работу, именно приоритети! 
потоков позволпт обеспечивати бв 1 Стродеиствие системвг К сожаленикз, сеичас 
конечнме полизователи воспринимакзт BbicoKyio загрузку процессора как сигнал, 
что приложение вншло из-под контролч. В будуидем мне хотелоси 6 bi, чтобн зтот 
фактор воспринималсл положителино, как знак того, что компи 10 тер активно об- 
рабатмвает информацикз длч полвзователч. Проблема в том, что если занлти про- 
цессор обработкои потоков с уровнем приоритета 8 и вмше, приложенил могут 
начати недостаточно бмстро реагировати на ввод даннмх полизователем. Hafleiocb, 
что в будуидеи версии Диспетчера задач в отчете о загрузке процессора будет фи- 
гурироватв также информацил об уровнчх приоритета потоков. Зто гораздо лучше 
поможет в диагностике проблем. 


Упоминемо наличии в пространстве имен System . Diagnostics классов Process 
и ProcessThread (впрочем, зто относитсн to.ti.ko к настолБнмм приложенггам, но не 
к приложениим Windows Store). Они содержат информацшо о состоннии процесса 
и потока с точки зренгга Windows. Зти классм предназначенм дли разработчиков, 
желагогцих паписатг. сервисное приложение на управлнемом коде или пмтагогцихси 
оснаститБ свои код инструментами, помогагогцими в отладке. Позтому даннме классм 
попали в пространство имен System.Diagnostics. Дли доступа к даннмм классам 
приложенинм необходимм специалг.нме права системм безопасности. Вм не сможете 
применитБ зти классм, к примеру, в приложенггах Silverlight или ASP.NET. 

С другои сторонм, приложенин могут восполвзоватвсн классами AppDomain 
и Thread, обеспечивагогцими просмотр средои CLR доменов и потоков. Длн работм 
с зтими классами по бо. п.шси части не требуетсл специалвнмх прав системм без- 
опасности, хоти некоторме операции доступнм то./п.ко при наличии определеннмх 
привилегии. 


Фоновне и активнме потоки 

В CLR все потоки делитсн на активнме (foreground) и фоновме (background). При 
завершении активнмх потоков в процессе CLR принудителБно завершает также 
все запугценнБге на зтот момент фоновћге потоки. При зтом завершение фоновБгх 
потоков происходит немедленно и без понвленгга исклгочении. 

Следователвно, активнБге потоки имеет смбгсл исполБЗОватБ длл исполненгга 
задании, которнге обизателБно требуетсл завершитБ — например, длн перемегценгга 
на диск даннБгх из буфера в памити. Фоноввге же потоки можно оставитв дли таких 
некритичнБгх задач, как пересчет лчеек злектроннБгх таблиц или индексирование 
записеи. Ведв зта работа может 6 бгтб продолжена и после перезагрузки приложе- 
нгга, а значит, нет необходимости насилБно оставлитБ приложение работатн, когда 
полБЗОвателБ пБгтаетсл его закрБгтБ. 
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Концепции активнмх и фоновмх потоков в CLR бмла введена дли лучшеи под- 
держки доменов приложении. Как вм знаете, в каждом домене может 6 мтб запувдено 
отделБное приложение, при зтом каждое такое приложение может иметБ собственнБпт 
фоновБШ поток. Даже если одно из приложении завершаетсн, заставллн завершитвсл 
свои фоноввш поток, среда CLR все равно должна функционироватв, поддерживаи 
осталБнвге приложении. И толбко после того как все приложенгш со всеми своими 
фоноввши процессами будут завершенБц можно будет уничтожитн весБ процесс. 

Следукиции код демонстрирует разницу между фоновнш и активнБ1м по- 
токами: 

using System; 

using System.Threading; 

public static class Program { 
public static void Main() { 

// Создание нового потока (по умолчаниго активного) 

Thread t = new Thread(Worker) ; 

// Преврашение потока в фоновми 
t . IsBackground = true; 

t.Start(); // Старт потока 

// В случае активного потока приложение будет работати около 10 секунд 
// В случае фонового потока приложение немедленно прекратит работу 
Console.WriteLine("Returning from Main"); 

} 

private static void Worker() { 

Thread.Sleep(10000); // Имитацил 10 секунд работи 

// Следугошал строка виводитсл толбко длл кода, 

// исполнлемого активнмм потоком 
Console.WriteLine("Returning from Worker"); 

} 

} 

Поток можно преврагцатБ из активного в фоноввш и обратно. Основнои поток 
приложенин и все потоки, в нвном виде созданнвш путем конструировангш обвекта 
Thread, по умолчаншо нвлиготси активнвши. А вот потоки из пула по умолчаниго 
нвлиготсн фоновБши. Также потоки, создаваемБШ машиннБш кодом и попадагогцие 
в управлнемуго среду исполнешш, помечаготси как фоноввге. 

ВНИМАНИЕ 

По возможности стараитесБ избегатБ активнБ1х потоков. Однажди менз попросили 
определитБ, почему приложение никак не может завершитБ своко работу. Прово- 
зившисб несколБко часов, л понлл, что причинои бмл компонент полБЗОвателБСкого 
интерфеиса, в лвном виде создаклции активнБ1и поток. После того как компонент 
заставили исполБЗОваш поток из пула, проблема бнла решена, а заодно noBbicnaacb 
и обидал зффективностБ работм приложенил. 
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Что далБше? 

В зтои главе мм рассмотрели основм работн с потоками. НадегосБ, вм усвоили, что 
поток исполненип пвлнетсн доволбно дорогим ресурсом и исполБЗОватБ его следует 
краине аккуратно. Лучше всего задеиствоватБ пул потоков средБ 1 CLR, которБш 
создает и уничтожает потоки автоматически. Пул предлагает набор потоков длл 
решенгш различнвгх задач, и некоторБге из зтих потоков вполне справлтси с реше- 
нием задач вашего приложенгш. 

В главе 27 мбг поговорим о том, каким образом пул потоков позволнет вбшолннтб 
ББгчислителБНБге операции. Глава 28 посвпгцена обсужденшо того, как с no.vmmi.io 
комбинации пула потоков и асинхроннои модели программировангш CLR вбшол- 
нитб операции ввода-вБшода. Во многих ситуациих асинхроннБге вБшислителБНБге 
операции и операции ввода-вБшода можно вбшолнитб таким образом, что синхро- 
низацин потоков вам вообгце не потребуетсл. Тем не менее остаготсл ситуации, 
в которвгх без синхронизации не обоитисн. Конструкции, применнемБге длн син- 
хронизации, и разница между ними рассматриваготсн в главах 29 и 30. 

В заклгочение упомнну, что л интенсивно исполБЗОвал потокгг, начинан с первои 
бета-версии Windows NT 3.1, поивившеиси примерно в 1992 году. После ввгхода 
бета-версии .NET н начал создаватв библиотеку классов, позволнгогцуго упроститв 
асинхронное программирование и синхронизациго потоков. Зту библиотеку (она 
назвгваетсн Wintellect Power Threading Library) можно загрузитв бесплатно. Сугце- 
ствугот ее версии дли обвгчнои средвг CLR, а также дли Silverlight CLR и Compact 
Framework. Наити библиотеку, документациго и примерБг кода можно по адресу 
http://Wintellect.com/PowerThreading.aspx. Там же находлтсл ссбглки на форум под- 
держки и на видеоролики с примерами исполБЗОвангш различнвгх компонентов 
библиотеки. 
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В зтои главе рассказмваетсл о различнмх способах асинхронного вмполнении 
операции, вмнесеннмх в отделвнме потоки. К вмчислителБнмм операцинм, в част- 
ности, относлтси компилнцин кода, проверка орфографии, проверка грамматики, 
пересчет злектроннБ1Х таблиц, перекодирование аудио- и видеоданнБ1х, создание 
миниатгор изображении. Как видите, такие операции встречаготсн в финансовБ 1 х 
и технических приложенгшх повсеместно. 

Болбшинство приложении не так уж много времени уделлет обработке находн- 
гцихсн в памнти даннћгх или вБгчисленгшм. Зто легко проверитБ, открБш Диспетчер 
задач на вкладке Performance (Бнстродеиствие). Загрузка процессора менее 100 % 
(а именно такаи картина наблгодаетсн в болвшинстве случаев), означает, что запу- 
гценнБге процессБг не исполБзугот на полнуго могцностб резервБг всех идер. Также 
зто означает, что некоторвге (если не все) потоки в процессах вообгце не испол- 
ннготсн. Они ждут операции ввода или ввгвода, например срабатБшангш таимера, 
чтенгш даннБгх из базБг или записи даннпгх в нее, нажатил клавиши на клавиатуре, 
перемегценгш указателл или нажатии кнопки мбгши. При операцинх ввода-вБшода 
драиверБг Microsoft Windows иницииругот работу устроиств, а сам процессор в зто 
времн не исполнпет потоки, запугценнБге в системе. Именно позтому диспетчер 
задач показвшает низкуго загрузку процессора. 

Однако даже приложенгш, предназначеннБге длл операции ввода-вБшода, об- 
рабатБшагот получаемБге даннБге, позтому распараллеливание ВБгаислении может 
значителБно повбгситб их пропускнуго способностк. В зтои главе рассказвшаетсл 
о пуле потоков обгцелзвгковои исполннгогцеи средвг и основнбгх приемах его ис- 
полБЗОвангш. Зто краине важнаи информацгш, так как пул потоков пвлиетси клго- 
чевои технологиеи, обеспечивагогцеи разработку и реализациго масштабируемвгх, 
бБгстрореагиругогцих и надежнБгх приложении и компонентов. Также в зтои главе 
рассказвшаетсн о механизмах, позволнгогцих вбшолннтб вБшислителБНБге операцгш 
посредством пула потоков. Зти операцгш происходит в асинхронном режиме, что 
позволнет, во-перввгх, обеспечитБ бБгструго реакциго на деиствии полвзователеи 
приложенгш с графическим интерфеисом, во-вторвгх, распределитв занимагогцие 
много времени ввгчисленгш между различнБгми процессорами. 

Пул потоков в CLR 

Как 6 бшо отмечено в предвгдугцеи главе, создание и уничтожение потока занимает 
изрндное времн. Кроме того, при наличгш множества потоков впустуго расходуетсн 
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na.viHTb и снижаетсн производителБностБ, ведБ операционнои системе приходитси 
планироватБ исполнение потоков и вмполннтб переклгоченин контекста. К счастБК), 
среда CLR способна управлнтБ собственнБш пулом потоков, то еств набором готовбш 
потоков, доступнБ 1 х дли исполБЗОванин приложенинми. Длл каждого зкземплира 
CLR сугцествует свои пул, исполвзуемБш всеми доменами приложении, находл- 
гцимисл под управлением зкземплира CLR. Если в один процесс загружаготсл 
несколвко зкземплнров CLR, длн каждого из них формируетсл собственнБпг пул. 

При инициализации CLR пул потоков пуст. В его внутреннеи реализации поддер- 
живаетсн очередв запросов на вБшолнение операции. Длл вБшолненин приложением 
асинхроннои операции вБ13Б1ваетсл метод, размегцагогции соответствугогции запрос 
в очереди пула потоков. Код пула извлекает записи из очереди и распределиет их 
среди потоков из пула. Если пул пуст, создаетсл новбш поток. Как уже отмечалосБ, 
создание потока отрицателкно сказБгваетсл на производителБности. Однако по 
завершенгш исполненгш своего заданин поток не уничтожаетсл, а возврагцаетсл 
в пул и ожидает следугогцего запроса. Посколвку поток не уничтожаетсл, произво- 
дителвностБ не страдает. 

Когда приложение отправллет пулу много запросов, он пвгтаетси обслужитБ их 
все с помогцбго одного потока. Однако если приложение создает очередк запросов 
бвгстрее, чем поток из пула их обслуживает, создаготсл дополнителБНБге потокгг. 
Такои подход позволнет обоитггсБ при обработке запросов неболБшггм количеством 
потоков. 

Когда приложенгге прекрагцает отправлнтв запросБг в пул, поивлнготсн незаннтвге 
потокгг, впустуго занимагогцие памитв. Позтому через некоторое времл бездеиствин 
(разлггчное длн разнвгх версгги CLR) поток пробуждаетси гг самоунггчтожаетсл, осво- 
бождал ресурсвг. Зто опнтб отрггцателБно сказБгваетсп на производителвности, но в 
данном случае зто уже не столб важно, посколвку уничтожаемБш поток все равно про- 
стаггвал, а значит, приложение в даннвги момент не 6 бгло особо загружено работои. 

Пул потоков позволиет наити компромггсс в ситуацгггг, когда малое количество 
потоков зкономггт ресурсвг, а болБшое позволнет восполвзоватБСн преимугцествами 
многопроцессорнБгх сггстем, а также многондернБгх гг гиперпотоковБгх процессоров. 
Пул потоков деиствует по звристическому алгорггтму. Если прггложение должно 
вБгполнитБ множество задании и при зтом имеготсл доступнвге процессорБг, пул 
создает болпше потоков. Пргг снижении загрузки приложенгш потокгг ггз пула 
самоунггчтожаготсл. 


Простше BbiHHC/iHTe/ibHbie операции 

Длн добавленип в очередв пула потоков асггнхроннБгх вбгчислит6лбнбгх операции 
обпгчно ББгзБгвагот одггн ггз следугогцггх методов класса ThreadPool: 

static Boolean QueueUserWorkItem(WaitCallback callBack); 

static Boolean QueueUserWorkItem(WaitCallback callBackj Object state); 
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Зти методм ставнт «рабочии злемент» вместе с дополнителБнмми даннмми 
состоинии в очередБ пула потоков и сразу isoanpamaiOT управление приложеншо. 
Рабочим злементом назмваетси указаннми в параметре callback метод, которми 
будет вмзван потоком из пула. Зтому методу можно передатБ один параметр 
через аргумент state (даншле состоинии). Без зтого параметра версии метода 
QueueUserWorkItem передает методу обратного вмзова значение null. Все заканчи- 
ваетсн тем, что один из потоков пула обработает рабочии злемент, приводн к вмзову 
указанного метода. Создаваемми метод обратного вмзова должен соответствоватБ 
делегату System.Threading.WaitCallback, которми определиетси так: 

delegate void WaitCallback(Object state); 

ПРИМЕЧАНИЕ 

Сигнатур ^1 делегатов VVaitCallback и TimerCallback (o нихмн поговорим в зтои главе), 
а также делегата ParameterizedThreadStart (он упоминалсп в главе 25) совпадакзт. 
Если Bbi определаете метод, совпадакшдии с зтои сигнатурои, он может бмти вмзван 
через MeTOflThreadPool.QueueUserWorkltem при помоиди обвекта System.Threading. 
Timer или System.Threading.Thread. 


Пример процедурм асинхронного вмзова метода потоком из пула: 

using System; 

using System.Threading; 

public static class Program { 
public static void Main() { 

Console.WriteLine("Main thread: queuing an asynchnonous operation"); 
ThreadPool.QueuellserWorkItem(ComputeBoundOpj 5); 
Console.WriteLine("Main thread: Doing other wonk here..."); 

Thread.Sleep(10000); // Имитацип другои работн (10 секунд) 
Console.WriteLine("Hit <Enter> to end this pnogram..."); 

Console.ReadLine(); 

} 

// Сигнатура метода совпадает c сигнатурои делегата WaitCallback 
private static void ComputeBoundOp(Object state) { 

// Метод вмполнлетсл потоком из пула 

Console.WriteLine("In ComputeBoundOp: state={0}", state); 

Thread.Sleep(1000); // Имитацин другои работм (1 секунда) 

// После возвраценил управленил методом поток 
// возврацаетсв в пул и ожидает следугацего заданил 

} 


Резулетат компилнции и запуска зтого кода: 

Main thread: queuing an asynchronous operation 
Main thread: Doing other work here... 

In ComputeBoundOp: state=5 
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Впрочем, возможен и такои резулБтат: 

Main thread: queuing an asynchronous operation 

In ComputeBoundOp: state=5 

Main thread: Doing other work here... 

РазнБш поридок следовании строк в данном случае обЂисннетси асинхроннБш 
вБшолнением методов. Планировшик Windows решает, какои поток должен Bbi- 
полннтбси первБш, или же планирует их дли одновременного ввшолнешш на 
многопроцессорном компБШтере. 

ПРИМЕЧАНИЕ 

Если метод обратного вмзова генерирует необработанное исклгочение, CLR заверша- 
ет процесс (если зто не противоречит политике хоста). Необработаннме исклкзченил 
обсуждалисБ в главе 20. 


ПРИМЕЧАНИЕ 

В приложенилх Windows Store класс System.Threading.ThreadPool недоступен длл 
открБ1того исполБЗОваниз. Впрочем, он косвенно исполизуетсл при исполвзовании 
типов из пространства имен System.Threading.Tasks (см. раздел «3аданил» далее 
в зтои главе). 


КонтекстБ! исполненил 

С каждБш потоком свизан определеннБнТ контекст исполненгш. Он вклгоча- 
ет в себн параметрБ 1 безопасности (сжатвги стек, своиство Principal обвекта 
Thread и идентификационнБге даннБге Windows), параметрБг хоста (System. 
Threading.HostExecutionContextManager) и контекстнБге даншле логического 
вБгзова (см. методБ 1 LogicalSetData и LogicalGetData класса System.Runtime. 
Remoting .Messaging . CallContext). Когда поток исполннет код, значешш параме- 
тров контекста исполненин оказвшагот влгшние на некоторБге операцгш. В идеале 
вснкии раз при исполБЗОвангш длл ввшолненгш задангш вспомогателБного потока 
в зтот вспомогателвнБш поток должен копироватБСи контекст исполненгш перво- 
го потока. Зто гарантирует исполБЗОвание одинаковБ1х параметров безопасности 
и хоста в обоих потоках, а также доступ вспомогателвного потока к даннпш, со- 
храненнБш в контексте логического ввгоова исходного потока. 

По умолчаниго CLR автоматически копирует контекст исполненгш самого 
первого потока во все вспомогателвнБге потоки. Зто гарантирует безопасностБ, 
но в угцерб производителБности, потому что в контексте исполненгш содержитси 
много информации. Сбор Bceii информацгш и ее копирование во вспомогателвнБге 
потоки занимает немало времени. ВспомогателБНБш поток может, в свого очередв, 
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исполћзоватћ вспомогателБнме потоки, при зтом создаготсл и инициализируготси 
дополнителБнме структурм даннмх. 

Класс ExecutionContext в пространстве имен System.Threading позволлет 
управлитБ копированием контекста исполненин потока. Вот как он вмглндит: 

public sealed class ExecutionContext : IDisposable, ISerializable { 
[SecurityCritical] public static AsyncFlowControl SuppressFlow(); 
public static void RestoreFlow(); 
public static Boolean IsFlowSuppressed(); 

// He показанм редко применлемме методн 

} 

С помогцбго зтого класса можно запретитБ копирование контекста исполнении, 
повмсив производителБностБ приложенил. Дли сервернмх приложении рост про- 
изводителБности в зтом случае оказмваетсл весБма значителБНБш. Длл клиентских 
приложении особои вб1годб1 нет, кроме того, метод SuppressFlow помечаетсл атри- 
бутом [SecurityCritical], в резулвтатестановитснневозможнвш вбтзов некоторБ 1 х 
клиентских приложении (например, Microsoft Silverlight). Разумеетсл, запрешатв 
копирование контекста исполненгш можно, толбко если вспомогателБному пото- 
ку не требуетсл содержагцалсн там информацгш. Когда иницииругогции контекст 
исполненгш не переходит во вспомогателБНБги поток, тот исполкзует последнии 
свнзаннБги с ним контекст исполненип. Позтому при отклгоченном копировании 
контекста поток не должен исполннтб код, зависнгции от состоннин текугцего кон- 
текста ггсполненгш (например, идентификационнБгх даннБгх полБЗОвателл Windows). 

Следугогции пример демонстрирует, как запрет на копирование контекста ис- 
полненгш влгшет на даннвге в контексте логического ввгзова потока при постановке 
рабочего злемента в очередв в CLR -пуле 1 : 
public static void Main() { 

// Помешаем даннме в контекст логического вмзова потока метода Main 
CallContext . LogicalSetData("Name", "leffrey"); 

// Заставлнем поток из пула работатБ 

// Поток из пула имеет доступ к даннмм контекста логического вмзова 
ThreadPool.QueueUserWorkItem( 

state => Console.WriteLine("Name={ 0 }", 

CallContext.LogicalGetData("Name"))); 

// Запретаем копирование контекста исполненин потока метода Main 
ExecutionContext.SuppressFlow( ); 

// Заставлнем поток из пула виполнитБ работу. 

// Поток из пула НЕ имеет доступа к даннмм контекста логического вмзова 
ThreadPool .QueueUserWorkItem( -. . 

прооолжение 


1 ДобавллемБге к контексту логического вБгзова злементвг должнбг 6бгтб сериализуемБгми 
(см. главу 24). Копирование контекста исполненил, содержагдего даннвге контекста логи- 
ческого вБгзова, краине отрицателвно сказБгваетсн на производителвности, так как требует 
серилизации и десериализации всех злементов даннвгх. 
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state => Console.WriteLine("Name={0}", 

CallContext.LogicalGetData("Name"))); 

// Восстанавливаем копирование контекста исполненил потока метода Main 
// на случаи будуцеи работн с другими потоками из пула 
ExecutionContext . RestoreFlow( ); 

Console . ReadLine( ) ; 

} 


РезулБтат компилнции и запуска зтого кода: 

Name=Deffrey 

Name= 

Пока Mbi обсуждаем толбко запрет копированин контекста исполненин при вбн 
зове метода ThreadPool.QueueUserWorkItem, но зтот прием исполћзуетсл как при 
работе с обвектами Task (см. раздел «3аданин» даннои главБ 1 ), так и при иниции- 
ровании асинхроннБ1х операции ввода-вБшода (о них речн идет в главе 28). 


Скоординированнал отмена 

Платформа .NET предлагает стандартнвп! паттерн операции отменБт Зтот паттерн 
ивлнетсл скоординированним (cooperative), то еств требует лвнои поддержки от- 
менБ 1 операции. Другими словами, как код, вбшолннкнции отменнемуго операциго, 
так и код, пБ1тагогциисн реализоватБ отмену, должнб1 относитбсн к типам, о которБ1Х 
рассказБшаетсл в зтом разделе. Так как необходимоств отменБ 1 занимагогцих много 
времени вБ1числителвнБ1х операции не вБИБшает сомненин, к вашим ввшислителв- 
нбш операцгшм имеет смбгсл добавитБ возможностб отмснбт О том, как зто сделатк, 
мб 1 и поговорим в зтом разделе. Но начатв следует с описангш двух ochobhbix типов 
из библиотеки FCL, входнгцих в состав стандартного паттерна скоординированнои 
отменБг 

Дли начала потребуетси обвект System . Threading . CancellationTokenSource. 
Вот как вмглндит даннБпг класс: 

public sealed class CancellationTokenSource : IDisposable { // Ссмлочнш тип 
public CancellationTokenSource(); 

public Boolean IsCancellationRequested { get; } 
public CancellationToken Token { get; } 

public void Cancel(); // BbBbiBaeT Cancel c аргументом false 
public void Cancel(Boolean throwOnFirstException); 

} 

Зтот обвект содержит все состоннгш, необходимвге длн управлнемои отменвг 
После созданин обвекта CancellationTokenSource (ссбшочнбш тип) получитБ 
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один или несколдко зкземплнров CancellationToken (значимми тип) можно из 
своиства Token. Затем они передаготсн операцинм, поддерживагошим отмену. Вот 
наиболее полезнме членм значимого типа CancellationToken: 

public stnuct CancellationToken { // Значимаи тип 

public static CancellationToken None { get; } // Очени удобно 

Boolean IsCancellationRequested { get; } // BbBbiBaeTcn операцинми, 

// не свнзаннмми c Task 

public void ThrowIfCancellationRequested(); // Вмзван операцивми, 

// свлзаннмми c Task 


// NaitHandle устанавливаетсл при отмене CancellationTokenSource 
public NaitHandle NaitHandle { get; } 

// Членм GetHashCode, Equals, == и != не показани 


public Boolean CanBeCanceled { get; } // Редко исполцзуетсл 


} 


public CancellationTokenRegistration Register( 

Action<Object> callback, Object state, 

Boolean useSynchronizationContext); // Более простме варианти 

// перегрузки не показани 


Зкземплнр CancellationToken относитсл к упрогценному значимому типу, 
так как содержит всего одно закрмтое поле: ссмлку на свои обвект Cancellation- 
TokenSource. Цикл вмчислителБнои операции может периодически обрагцатћсл 
к своиству IsCancellationRequested обвекта CancellationToken, чтобм узнатБ, 
не требуетсл ли раннее завершение его работБц то естБ прерБшание операции. Про- 
цессор перестает совершатн операции, в резулвтате которвш bbi не заинтересованБг 
Рассмотрим пример кода: 

internal static class CancellationDemo { 
public static void Main() { 

CancellationTokenSource cts = new CancellationTokenSource(); 

// Передаем операции CancellationToken и число 
ThreadPool.QueueUserWorkItem(o => Count(cts.Token, 1000)); 

Console.WriteLine("Press <Enter> to cancel the operation."); 

Console.ReadLine(); 

cts.Cancel(); // Если метод Count уже вернул управленин, 

// Cancel не оказмвает никакого зффекта 

// Cancel немедленно возврашает управление, метод продолжает работу... 

Console . ReadLine( ); 

} 

private static void Count(CancellationToken token, Int32 countTo) { 
for (Int32 count = 0; count <countTo; count++) { 
if (token.IsCancellationRequested) { 


продолжение & 
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Console.Writel_ine("Count is cancelled"); 
break; // Вмход их цикла дла остановки операции 

} 

Console.WriteLine(count); 

Thread.Sleep(200); // Длл демонстрационнмх целеи просто ждем 

} 

Console.WriteLine("Count is done"); 

} 

} 


ПРИМЕЧАНИЕ 

Чтоб bi предотвратит^ отмену операции, еи можно передати зкземпллр 
CancellationToken, возвраиденнми статическим своиством None структурм 
CancellationToken. Зто очени удобное своиство возвраидает cnepnanbHbin зкземпллр 
CancellationToken, не свчзаннми с каким-либо обЂектом CancellationTokenSource (его 
закри 1 тое поле имеет значение null). При отсутствии обЂекта CancellationTokenSource 
отсутствует и код, которђш может вмзватЂ метод Cancel. А значит, запрос к своиству 
lsCancellationRequested упомлнутого зкземпллра CancellationToken всегда будет полу- 
чатЂ в ответ значение false. Аналогичнал ситуацил с запросом к своиству CanBeCanceled . 
Значение true возвраидаетсл толвко длч зкземпллров CancellationToken, полученнЂ 1 х 
через своиство Token перечисленил CancellationTokenSource. 


При желании можно зарегистрироватБ один или несколБКО методов таким 
образом, что 6 б 1 они ББ13Б1валисБ при отмене обвекта CancellationTokenSource. 
Дли регистрации метода обратного вБ130ва следует передатБ методу Register 
структурБд CancellationToken делегата Action<Object> состолние, которое 
Bbi предполагаете передатБ через делегат в метод обратного вБ130ва, и значение 
типа Boolean, указБшакпцее, должен ли вБкзБшатБСи делегат с исполБЗОванием 
контекста SynchronizationContext вБВБшакпцего потока. Если передатБ в пара- 
метре useSynchronizationContext значение false, поток, вБ13Бшакшдии метод 
Cancel, последователБно запустит все зарегистрированнБге методБ 1 . При пере- 
даче же значенин true обратпте вб130вб 1 отсБшаготсн фиксированному обвекту 
SynchronizationContext, которБш вБ 1 бирает, какои из потоков активизирует тот 
или iiHoii обратнБш вбгоов. Подробно класс SynchronizationContext рассматри- 
ваетси в главе 28. 

ПРИМЕЧАНИЕ 

Если Bbi регистрируете метод обратного внзова, исполвзул уже отмененнвш обвект 
CancellationTokenSource, поток, Bbi3biBaiouLnH метод Register, активизирует обратнми 
вмзов (верочтно, через SynchronizationContext Bbi3biBaiOL4ero потока, если в параметре 
useSynchronizationContext передано значение true). 


МногократнБш вбгзов метода Register приводит к многократнои же активизации 
методов обратного вБгзова, причем последние могут генерироватБ необработанное 


Скоординированнал отмена 755 


исклгочение. Если вшзватћ метод Cancel обвекта CancellationTokenSource с па- 
раметром true, первБш же метод обратного вћиова, ставшии источником необрабо- 
танного искл10чспим, остановитввшолнениеосталБНБ1хметодов обратного вБ130ва, 
а иск почепие будеттакже сгенерировано методом Cancel. Если же передатв зтому 
методу значение f alse, будут вБ13ванБ1 все зарегистрированнвге методБ 1 обратного 
вБ130ва. Все понвлнгогциесн при зтом необработаннвге исклгоченич добавлнготси 
в коллекциго. Если после завершенин всех методов обратного ввгзова обнаружива- 
етсл наличие необработаннвгх исклгочении, метод Cancel генерирует исклгочение 
AggregateException, своиству InnerExceptions которого присваиваетсн коллекцин 
сгенерированнБгх обвектов исклгочении. При отсутствии необработаннвгх исклго- 
чении метод Cancel просто возврагцает управление. 


ВНИМАНИЕ 

Невозможно определитБ, с какои операциеи свазан тот или инои обвект из коллекции 
lnnerExceptions исклкзченил AggregateException. То естБ Bbi фактически получаете 
толбко информацииз о том, что некоторне операции BbinonHeHbi не 6бши, и по типу 
исклк)ченип можете определитБ, в чем 6bma причина такого поведенин. 4To6bi bw- 
acHHTb местоположение ошибки, нужно исследовати своиство StackTrace обвекта 
исклк>ченил и вручнукз проверити исходни 1 и код. 


Метод Register обвекта CancellationToken возврагцает структуру Cancellation- 
TokenRegistration, котораи вбггллдит следугогцим образом: 

public struct CancellationTokenRegistration : 

IEquatable<CancellationTokenRegistration>, IDisposable { 
public void Dispose(); 

// He показанм GetHashCode, Equals, операторн == и != 

} 

Метод Dispose позволнет удалитв из обвекта CancellationTokenSource за- 
регистрированнБпТ обратнБги вбгзов, с которвгм свизан даннБнТ обвект. В ре- 
зулБтате при вБгзове метода Cancel зтот обратнвпТ вбгзов игнорируетсн. Вот 
код, демонстриругогции регистрациго двух обратнвгх вбгзовов с одним обвектом 

CancellationTokenSource: 

varcts = new CancellationTokenSource( ); 

cts.Token.Register(() => Console.WriteLine("Canceled 1")); 
cts.Token.Register(() => Console.WriteLine("Canceled 2")); 

// Длн проверки отменим его и внполним оба обратннх внзова 
cts.Cancel(); 

Вот резулкгат работБг такого кода, полученнБпТ сразу после вБгзова метода Cancel: 

Canceled 2 
Canceled 1 
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Наконец, можно создатт> новми обвект CancellationTokenSource, свнзав друг 
с другом другие обвектм CancellationTokenSource. Отмена зтого нового обвекта 
произоидет при отмене лтбого из входлгцих в его состав обвектов. Вот демонстри- 
руклции зто код: 

// Создание обнекта CancellationTokenSource 
var ctsl = new CancellationTokenSource(); 

ctsl.Token.Register(() => Console.WriteLine("ctsl canceled")); 

// Создание второго обиекта CancellationTokenSource 
var cts2 = new CancellationTokenSource(); 

cts2.Token.Register(() => Console.WriteLine("cts2 canceled")); 

// Создание нового обБекта CancellationTokenSource, 

// отменлемого при отмене ctsl или ct2 

var linkedCts = CancellationTokenSource.CreateLinkedTokenSource( 
ctsl.Token, cts2.Token); 

linkedCts.Token.Register(() => Console.WriteLine("linkedCts canceled")); 

// Отмена одного из обБектов CancellationTokenSource (n внбрал cts2) 
cts2.Cancel(); 

// Показмваем, какои из обнектов CancellationTokenSource бнл отменен 
Console.WriteLine("ctsl canceled={0} , cts2 canceled={l}, linkedCts={2}", 
ctsl.IsCancellationRequested, cts2.IsCancellationRequested, 
linkedCts.IsCancellationRequested); 

РезулБтат запуска зтого кода: 
linkedCts canceled 
cts2 canceled 

ctsl canceled=False, cts2 canceled=True, linkedCts=True 

Часто требуетсн отменитБ операцгпо по нстечении определенного периода време- 
ни. Например, представвге, что серверное приложение начало вбшолннтб некоторБге 
ВБГчисленил по запросу клиента. При зтом серверное приложение должно гаран- 
тированно ответитБ клиенту не позже двух секунд. В некоторвгх ситуацилх лучше 
получитв ответ с ошибкои или неполнвши резулБтатами, чем дожидатБСч полного 
резулБтата в течение долгого времени. К счаствго, класс CancellationTokenSource 
умеет инициироватБ собственнуго отмену по истечении заданного интервала. Длн 
зтого следует либо создатв обвект CancellationTokenSource одним из конструк- 
торов, получагогцих величину задержки, либо ввгзватв метод CancelAfter класса 
CancellationTokenSource. 

public sealed class CancellationTokenSource : IDisposable { // Ссмлочнми тип 

public CancellationTokenSource(Int32 millisecondsDelay); 
public CancellationTokenSource(TimeSpan delay); 

public void CancelAfter(Int32 millisecondsDelay); 
public void CancelAfter(TimeSpan delay); 


} 
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Задани^ 

ВмзватБ метод QueueUserWorkItem класса ThreadPool длн запуска асинхроннмх 
вмчислителБНБ1х операции оченв просто. Однако зтот подход имеет множество 
недостатков. Самои болвшои проблемои ивлиетсл отсутствие встроенного меха- 
низма, позволигогцего узнатв о завершении операции и получитв возврагцаемое 
значение. Дли обхода зтих и других ограничении специалистБ1 Microsoft ввели 
поннтие заданип (tasks), ввшолнение которБ 1 х осугцествлнетсн посредством типов 
из пространстваимен System.Threading.Tasks. 

Вот каким образом при помогци задании вБшолннетси операцин, аналогичнаи 
вБ 130 ву метода QueueUserWorkItem класса ThreadPool: 

ThreadPool.QueueUserWorkItem(ComputeBoundOp, 5); // Визов QueueUserWorkItem 
new Task(ComputeBoundOp, 5).Start(); // Аналог предидутеи строки 

Task.Run(() => ComputeBound0p(5)); // Eu;e один аналог 

Bo второи строке после созданин нового обвекта Task немедленно вБШБшаетси 
метод Start длн запуска задангш. Естественно, bbi можете создатБ обвект Task и вбн 
зватБ Start длл него позднее. Можно также представитБ код, передатогции созданнБпг 
им обвект Task какому-то стороннему методу, которнш и будет определнтБ момент 
вБ 130 ва метода Start. Посколвку создание обвекта Task с немедленнкш вбшовом 
Start вБшолннетсл так часто, также можно восполБЗОватБСн удобнБш статическим 
методом Run класса Task, как показано в последнеи строке. 

Д лн создангш обвекта Та s k следует ввшватБ конструктор и передатк ему делегата 
Action или Action<Object>, указБшагогцего, какуго операциго вбг хотите вбшол- 
нитб. При передаче метода, ожидагогцего тип Object, в конструктор обвекта Task 
следует передатв также аргумент, которкш должен 6бгтб в итоге передан операции. 
При вБгзове Run передаетсл делегат Func<TResult> или Action, определлгогции 
вБшолниемуго операциго. Также конструктору можно передатн егце и структуру 
CancellationToken, позволнгогцуго отменитв обвект Task до его вБшолненгш (зта 
процедура подробно рассмотрена далее). 

При желании конструктору можно передаватБ флаги из перечисленгш 
TaskCreationOptions, управлнгогцие способами вБшолненгш задании. ЗлементБг 
перечисленгш определлгот набор флагов, которвге могут комбинироватБСн по- 
разриднои операциеи ИЛИ. Перечисление TaskCreationOptions определнетсл 
следугогцим образом: 

[Flags, Serializable] 

public enumTaskCreationOptions { 

None = 0x0000, // По умолчаник) 

// Сообтает планировцику, что задание должно 6biTb поставлено 
// на виполнение по возможности скорее 
PreferFairness = 0x0001, 

// Сообцает планировшику, что ему следует более активно 

продолжение & 
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// создаватв потоки в пуле потоков. 

LongRunning = 0x0002, 

// Всегда учитнваетсл: присоединлет задание к его родителк) 
AttachedToParent = 0x0004, 

// Если задача пмтаетсв присоединитвсв к родителБСкои задаче, 

// она интерпретируетсв как обћ 1 чнав, а не как дочернвл задача. 
DenyChildAttach = 0x0008, 

// Заставллет дочерние задачи исполвзовати планировцик по умолчаниго 
// вместо родителвского планировцика. 

HideScheduler = 0x0010 

} 


Болбшинство зтих флагов ивлиготсл рекомендацилми, которвге могут ис- 
полБЗОватБСн, а могут и игнорироватБСл обвектом планировгцика задании 
TaskSchedulen; всегда принимаготсн к вБшолненшо толбко флаги AttachedToParent, 
DenyChildAttach и HideSchedulen, которБШ никак не свнзанБ1 с самим обвектом 
TaskSchedulen. Более подробно про зтот обЂект Mbi поговорим чутБ позже. 


Завершение заданив и получение резулвтата 

Можно дождатБСн завершенин задании и после зтого получитБ резулБтат его вби 
полненгш. Рассмотрим метод Sum, которБш при болиших значенинх переменнои n 
требует болБшои вБшислителБнои могцности: 

private static Int32 Sum(Int32 n) { 

Int32 sum = 0; 
for (; n > 0; n--) 

checked { sum += n; } // при болвших n втдаетсв System.OverflowException 
return sum; 

} 

Можно создатБ обвект Task<TResult> (производнБш от oo'beiaaTask) ив каче- 
стве универсалБного аргумента TResult передатБ тип резулитата, возврагцаемого 
вБшислителБнои операциеи. Затем остаетсл дождатБСн завершенгш вБшолннгогцегосл 
задангш и получитБ резулБтат при помогци следугогцего кода: 

// Создание заданив Task (оно пока не вуполнветсв) 

Task<Int32> t = new Task<Int32>(n => Sum((Int32)n), 1000000000); 

// Можно начатБ вмполнение заданив через некоторое времн 
t.Start(); 

// Можно ожидатБ завершенив заданив в ввном виде 
t.Wait(); // ПРИМЕЧАНИЕ. Суцествует перегруженнав версив, 

// принимагоцав таим-аут /CancellationToken 


// Получение резулБтата (своиство Result вмзмвает метод Wait) 
Console.WriteLine("The Sum is: " + t.Result); // Значение Int32 



Заданил 759 


ВНИМАНИЕ 

При вшове потоком MeTOflaVVait система проверчет, началосв ли вмполнениезаданил 
Task, которого ожидает поток. В случае положителиного резулвтата проверки поток, 
вмзмвакиции метод Wait, блокируетсл до завершенил заданил. Но если задание еш,е 
не начало вмполнлтвсл, система может (в зависимости от обвекта TaskScheduler) 
вмполнитв его при помоиди потока, внзнвак>ш,его метод Wait. В зтом случае дан- 
Hbin поток не блокируетсл. Он внтолнлет задание Task и немедленно возвра 1 дает 
управление. Зто снижает затратм ресурсов (вам не приходитсл создавати поток 
взамен заблокированного), повмшает производителвноств (на создание потока 
и переклкзчение контекста не тратитсл времл). Однако и зто может бмтш не оченв 
хорошо. Например, если перед вмзовом MeTOflaWait в рамкахсинхронизации потока 
происходит его блокирование, а затем задание пмтаетсл получиљ доступ к тем же 
запертмм ресурсам, возникает взаимнал блокировка (deadlock)! 


Если вмчислителћное задание генерирует необработанное исклгочение, оно по- 
г.тошастсм и сохраниетсн в коллекции, а потоку пула разрешаетсн вернутБСи в пул. 
Затем при вмзове метода Wait или своиства Result зти членм вброснт исклгочение 

System.AggregateException. 

Тип AggregateException инкапсулирует коллекциго исклгочении (которме 
генерируготси, если родителБСКое задание порождает многочисленнме дочерние 
задании, приводигцие к исклгочениим). Он содержит своиство InnerExceptions, 
lioanpamaioiucc обвект ReadOnlyCollection<Exception>. Не следует путатБ его со 
своиством InnerException, наследуеммм классом AggregateException от своего 
базового класса System . Exception. Скажем, в показанном ранее примере атс.мепт 0 
своиства InnerExceptions класса AggregateException будет ссмлатБСи на обвект 
System.OverflowException, порождаемми вмчислителћнмм методом (Sum). 

Длн удобства класс AggregateException переопределиет метод GetBaseException 
класса Exception. Зта реализации возврагцает исклгочение с максималБнмм уров- 
нем вложенности, которое и считаетсл источником проблемм (предполагаетси, 
что такое исклгочение в коллекции всего одно). Класс AggregateException также 
предлагает метод Flatten, создакнции новми зкземплнр AggregateException, 
своиство InnerExceptions которого содержит список исклгочении, вброшеннмх 
после перебора внутреннеи иерархии исклгочении первоначалБного обвекта. Ну 
и наконец, даннми класс содержит метод Handle, вмзмвагогции дли каждого из 
исклгочении в составе AggregateException метод обратного вмзова. Зтот метод 
вмбирает способ обработки исклгоченин. Длл обрабатмваеммх исклгочении он 
возврагцает значение true, дли необрабатмваеммх, соответственно, — f alse. Если 
после вмзова метода Handle остаетси хотн бм одно необработанное исклгочение, 
создаетсн HOBMrio6BeKTAggregateException. Впрочем, с методами Flatten nHandle 
мм подробно познакомимсн чутБ позже. 

Можно ожидатБ завершенгш не толбко одного задангш, но и массива обвектов 
Task. Длл зтого в одноименном классе сугцествует два статических метода. Ме- 
тод WaitAny блокирует вбгоов потоков до завершенгш ввшолненгш всех обвектов 
в массиве Task. Зтот метод возврагцает индекс типа Int32 в массив, содержагции 
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завершешше заданин, заставлин поток продолжитБ исполнение. Если проис- 
ходит таим-аут, метод возврапдает — 1. Отмена же метода посредством структурм 

CancellationToken приводит к исклгочениго OperationCanceledException. 

ВНИМАНИЕ 

Если bw ни разу не Bbi3biBaan методв! Wait или Result и не обраидалиси к своиству 
Exception класса Task, код не «узнает» о полвившихсл исклкзченилх. Иначе говорл, 
Bbi не получите информации о том, что программа столкнуласи с неожиданнои 
проблемои. Длл распознаванил скрмтнх исклкзчении можно зарегистрировати ме- 
тод обратного Bbi 30 Ba со статическим собмтием UnobservedTaskException класса 
TaskScheduler. При уничтожении заданип со CKpbiTbiM исклкочением в ходе уборки 
мусора зто собмтие активизируетсп потоком финализации уборпдика мусора CLR. 
После зтого обработчику co6biTnn передаетсл обвект UnobservedTaskExceptionEve 
ntArgs, содержапдии скритое исклкочение AggregateException. 


Статическии метод WaitAll класса Task блокирует вмзмвагопдии поток до за- 
вершенин всех обвектов Task в массиве. Метод возврапдает значение tnue после 
завершенип всех обвектов и значение f alse, если истекает времн ожидании. От- 
мена зтого метода посредством структурм CancellationToken также приводит 
к исклгочениго OperationCanceledException. 


Отмена заданил 

Дли отменм заданин можно восполБЗОватмш обвектом CancellationTokenSource. 
Впрочем, сначала нам следует отредактироватв метод Sum, дав ему возможностб 
работатБ со структурои CancellationToken: 

private static Int32 Sum(CancellationTokenctj Int32 n) { 

Int32 sum = 0; 
for (; n > 0; n--) { 

// Следуклцап строка приводит к исклтченик) OperationCanceledException 
// при вмзове метода Cancel длл обБекта CancellationTokenSource, 

// на которни ссмлаетсл маркер 
ct.ThrowIfCancellationRequested( ); 

checked { sum += n; } // при болБших n попвлпетсл 

// исклтчение System.OverflowException 

} 

return sum; 

} 


B зтом коде цикл вБшислителБнои операции периодически впгзБшает метод 
ThrowIfCancellationRequested класса CancellationToken, чтобкг проверитБ, 
не попвилсн ли запрос на отмену операции. Зтот метод аналогичен своиству 
IsCancellationRequested класса CancellationToken, рассмотренному ранее. 
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Однако при отмене обнекта CancellationTokenSource метод генерирует исклго- 
чение OperationCanceledException. Причинои исклгочении становитси тот факт, 
что в отличие от рабочих злементов, запугценнмх методом QueueUserWorkItem 
класса ThreadPool, задании поддерживагот концепциго вмполненгш и даже могут 
возвратцатБ значение. СледователБно, нужен способ, позволнгогции отличитб за- 
вершенное задание от незавершенного. Именно длл зтого применнетсл исклгочение. 
Создадим обвектБ 1 CancellationTokenSource и Task: 

CancellationTokenSource cts = new CancellationTokenSource(); 

Task<Int32> t = new Task<Int32>(() => Sum(cts.Token, 10000), cts.Token); 

t.Stant(); 

// Позднее отменим CancellationTokenSource, чтоби отменити Task 
cts.Cancel(); // Зто асинхроннми запрос, задача уже может бмти завершена 

try { 

// В случае отменш заданин метод Result генерирует 
// искличение AggregateException 

Console.WriteLine("The sum is: " + t.Result); // Значение Int32 

} 

catch (AggregateException х) { 

// Считаем обработаннмми все обБекти OperationCanceledException 

// Все осталБние исклшченин попадашт в новми обиект AggregateException, 

// СОСТОН 1 ДИИ тол bKO из необработанншх исклшчении 
x.Handle(e => е is OperationCanceledException) ; 

// Строка вшполннетсн, если все исклшченид уже обработанш 
Console.WriteLine("Sum was canceled"); 

} 

СоздаваемБ 1 и обвект Task можно свизатБ с обвектом CancellationToken, 
передав его конструктору Task (как показано ранее). Если отменитв обвект 
CancellationToken до планированин заданин, задание тоже будет отменено 1 . Однако 
если задание уже начало вбшолнитбсн (при помогци метода Start), его код должен 
в нвном виде поддерживатв отмену. К сожалениго, несмотрн на то что с обвектом 
Task свнзан обвект CancellationToken, у вас нет доступа к последнему. То еств вб 1 
должнб 1 каким-то образом поместитк тот же самип обвект CancellationToken, 
которБпг исполБЗОвалсн при созданин обвекта Task, в код задангш. Прогце всего прн 
написании зтого кода восполБЗОватБСи лимбда-вБгражением и <<передатБ» обвект 
CancellationToken в качестве переменнои замвгкангш (что, собственно, и 6 бшо 
сделано в предвгдугцем примере). 


1 Попнтка отменитБ задание до начала его вмполненин приводит к понвленшо исклгоченгш 
InvalidOperationException. 
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Автоматическии запуск заданил 
по завершении предндушего 

Длл написанил масштабируемого программного обеспеченгш следует избегати 
блокировки потоков. Вмзов метода Wait или запрос своиства Result при неза- 
вершенном задании приведет, скорее всего, к понвленшо в пуле нового потока, что 
увеличит расход ресурсов и отрицателБно скажетсл на расширлемости. К счастБго, 
сугцествует способ узнатБ о завершении заданин. Оно может просто инициироватв 
вБшолнение следугогцего заданил. Вот как следует переписатк предБгдугции код, 
что6б1 избежатБ блокировки потоков: 

// Создание обнекта Task с отложеннмм запуском 

Task<Int32> t = Task.Run(() => Sum(CancellationToken . None, 10000)); 

// Метод ContinueWith возврацает обнект Task, но обмчно 
// он не исполБзуетсн 

Task cwt = t.ContinueWith(task => Console.WriteLine( 

"The sum is: " + task.Result)); 

Теперв, как толбко задание, вБшолннгогцее метод Sum, завершитсн, оно инициирует 
вБшолнение следугогцего заданин (также на основе потока из пула), которое ввшедет 
резулБтат. Исполннгогции зтот код поток не блокируетси, ожидал завершенгш каж- 
дого из указаннвгх задании; он может в зто времн исполннтб какои-то другои код 
или, если зто поток из пула, вернутБСн в пул длн решенгш других задач. Обратите 
внимание, что вБшолннгогцее метод Sum задание может завершитБСн до вбгзовд ме- 
тода ContinueWith. Впрочем, зто не проблема, так как метод ContinueWith заметит 
завершение задангш Sum и немедленно начнет вБшолнение задангш, отвечагогцего 
за вбшод резулвтата. 

Также следует обратитк внимание на то, что метод ContinueWith возврагцает 
ссвглку на новбпг обгБСкт Task (в моем коде она помегцена в переменнуго cwt). При 
помогци зтого обвекта можно вБгзвшатБ различнБге членБг (например, метод Wait, 
Result или даже ContinueWith), но о6бгчно он просто игнорируетсл, а ссишка на 
него не сохраниетсп в переменнои. 

Следует также упоминутв, что во внутреннеи реализации обвект Та sk содержит 
коллекциго ContinueWith. Зто дает возможностб несколБКО раз вкгзватБ метод 
ContinueWith при помогци единственного обвекта Task. Когда зто задание завер- 
шитсл, все задангш из коллекции ContinueWith окажутсн в очереди в пуле потоков. 
Кроме того, при ввгзове метода ContinueWith можно установитв флаги перечис- 
ленгш TaskContinuationOptions. ПервБге шестБ флагов — None, PneferFairness, 
LongRunning, AttachedToParent, DenyChildAttach и HideScheduler — аналогичнБг 
флагампоказанного ранее перечисленгш TaskCreationOptions. Вот как вбгглндит 
тип TaskContinuationOptions: 

[Flags, Serializable] 

public enumTaskContinuationOptions { 

None = 0x0000, // По умолчаншо 


// Сообцает планировцику, что задание должно 6biTb поставлено 
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// на внполнение по возможности скорее 
PneferFairness = 0x0001, 

// Сообшает планировшику, что ему следует более активно 
// создаватн потоки в пуле потоков. 

LongRunning = 0x0002, 

// Всегда учитиваетсп: присоединлет задание к его родителк) 

AttachedToParent = 0x0004, 

// Если задача пмтаетсп присоединитнсв к родителн.скои задаче, 

// она интерпретируетсп как обћпнап, а не как дочернпд задача. 

DenyChildAttach = 0x0008, 

// Заставлпет дочерние задачи исполнзоватн планировшик по умолчаник) 

// вместо родителнского планировшика. 

HideSchedulen = 0x0010, 

// Запрешает отмену до завершенин предшественника. 

LazyCancellation = 0x0020, 

// Зтот флаг устанавливагат, когда требуетсл, чтобш поток, 

// вшполнлккции первое задание, вшполнил и задание ContinueWith . 

// Если первое задание уже завершено, поток, вшзшвакиции ContinueWith, 

// вшполнлет задание ContinueWith 
ExecuteSynchnonously = 0x80000, 

// Зти флаги указшвашт, когда запускати задание ContinueWith 
NotOnRanToCompletion = 0x10000, 

NotOnFaulted = 0x20000, 

NotOnCanceled = 0x40000, 

// Зти флаги лвллкјтсп комбинациеи трех предшдуших 
OnlyOnCanceled = NotOnRanToCompletion | NotOnFaulted, 

OnlyOnFaulted = NotOnRanToCompletion | NotOnCanceld, 

OnlyOnRanToCompletion = NotOnFaulted | NotOnCanceled, 

} 

При вмзове метода ContinueWith флаг TaskContinuationOptions .OnlyOn- 
Canceled показмвает, что новое задание должно вмполнитбсн толбко в случае от- 
менм предмдушего. Аналогично, ^^arTaskContinuationOptions.OnlyOnFaulted 
дает поннтб, что вмполнение нового заданин должно начатћси толбко после того, 
как первое задание станет источником необработанного исклточспин. Ну а при 
помоши флага TaskContinuationOptions .OnlyOnRanToCompletion вм програм- 
мируете запуск нового заданин толбко при условии, что предмдугцее задание не 
бмло отменено и не создало необработанного исклгоченил, а бмло вмполнено 
полностбго. Без зтих флагов новое задание запускаетсн вне зависимости от того, 
как завершилосв предмдугцее. После завершенин обвекта Та s k автоматически 
отменнготсн все его вмзовм с незапугценнмми задангшми. Вот пример, демон- 
стриругогции сказанное: 
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// Создание и запуск заданил с продолжением 
Task<Int32> t = Task.Run(() => Sum(10000)); 

// Метод ContinueWith возврашает обнект Task, но обмчно 
// он не исполизуетсл 

t.ContinueWith(task => Console.WriteLine("The sum is: " + task.Result), 
TaskContinuationOptions.OnlyOnRanToCompletion); 

t.ContinueWith(task => Console.WriteLine("Sum threw: " + task.Exception), 
TaskContinuationOptions.OnlyOnFaulted); 

t.ContinueWith(task => Console.WriteLine("Sum was canceled"), 
TaskContinuationOptions.OnlyOnCanceled); 


Дочерние заданич 

Как демонстрирует даннми код, задашш поддержива 10 т в числе прочего и отноше- 
нил предок-потомок: 

Task<Int32[ ]> parent = new Task<Int32[ ]>(() => { 

var results = new Int32[3]; // Создание массива длл резулитатов 

// Создание и запуск 3 дочерних задании 
new Task(() => results[0] = Sum(10000), 

TaskCreationOptions.AttachedToParent).Start(); 
new Task(() => results[l] = Sum(20000), 

TaskCreationOptions.AttachedToParent).Start(); 
new Task(() => results[2] = Sum(30000)j 

TaskCreationOptions.AttachedToParent).Start(); 

// Возврацаетсл ссмлка на массив 
// (злементн могут 6biTb не инициализированн) 
return results; 

}); 

// Внвод резулцтатов после завершенил родителцского и дочерних задании 
varcwt = parent.ContinueWith( 

parentTask => Аггау. ForEach(parentTask.Result, Console.WriteLine)); 

// Запуск родителцского заданил, которое запускает дочерние 
parent.Start(); 

РодителБское задание создает и запускает три обљекта Task. По умолчаншо за- 
дании-потомки попадагот на самми верхнии уровенв и не имегот отношенин к сво- 
ему предку. Однако при установке флага TaskCreationOptions . AttachedToParent 
родителБСКое задание завершаетсл толбко после завершенгш всех его потом- 
ков. Если при создании обвекта Task методом ContinueWith установитБ флаг 
TaskContinuationOptions .AttachedToParent, то задание, запускаемое после за- 
вершенгш предБвдугцего, станет его потомком. 
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Структура заданил 

Каждми о 6 ђ 6 Кт Task состоит из набора полеи, определикицих состоиние заданин. 
В их число входлт: идентификатор типа Int32 (предназначенное толђко длн чтенин 
своиство Id обвекта Та sk), значение типа Int32, представлнгошее состонние вмпол- 
ненин заданин, ссмлка на родителБСКое задание, ссмлка на обвект TaskSchedulen, 
показмваговдии времи созданин заданин, ссмлка на метод обратного вмзова, ссмлка 
на обвект, которми следует передатБ в метод обратного ввгоова (зтот обвект досту- 
пен через предназначенное толбко длн чтенгш своиство AsyncState обвекта Tas k), 
ссБшка на класс ExecutionContext и ссвшка на обнект ManualResetEventSlim. 
Кроме того, каждБ 1 и обБект Task имеет сскшку на дополнителБное состоиние, соз- 
даваемое по требованиго. Зто дополнителвное состоиние вклгочает в себи обвект 
CancellationToken, коллекциго обвектов ContinueWithTask, коллекциго обвектов 
Task длл дочерних задании, ставших источником необработаннвш исклгочении, 
и прочее в том же духе. За все зти возможности приходитсл платитв, так как длн 
храненин каждого состоннин требуетсл вбвдсллтб место в памлти. Если дополнителв- 
нБ1е возможности вам не нужнБц длн более зффективного расходовашш ресурсов 
рекомендуем восполБЗОватБСн методом ThreadPool . QueueUserWorkItem. 

КлассБ1 Task и Task<TResult> реализугот интерфеис IDisposable, что позволнет 
после завершенгш работБ1 с обБектом Task вБ 13 ватБ метод Dispose. Пока что зтот 
метод всего лишб закрБшает обБект ManualResetEventSlim, но можно определитБ 
классБц производнБге от Task и Task<TResult>, которБге будут ВБвделнтБ свои ресур- 
сб 1 , освобождаемБШ при помотци переопределенного метода Dispose. Разумеетси, 
разработчики практически никогда не вБИБшагот метод Dispose д.;ш обБекта Task; 
они просто позволигот уборгцику мусора удалитв освободившиесл ресурсвг 

Как легко заметитк, у каждого обкекта Task естк поле типа Int32, содержагцее 
уникалБНБШ идентификатор задангш. При создании обкекта зто поле инициализи- 
руетсн нулем. При первом обрагцении к своиств Id (доступному толбко длн чтенин) 
в поле заноситсн значение типа Int32, которое и возврагцаетсн в качестве резулвтата 
запроса. Нумерацгш идентификаторов начинаетсл с единицБ1 и увеличиваетсл на 
единицу с каждвш следугогцим присвоеннБш идентификатором. Что 6 б 1 заданиго 6 бш 
присвоен идентификатор, достаточно открвшв о 6 ђскт Task в отладчике Microsoft 
Visual Studio. 

ИдентификаторБ 1 6 бши введешл длн того, что 6 б 1 каждому заданиго соответство- 
вал уникалБНБШ номер. В Visual Studio идентификаторБ 1 можно увидетБ в окнах 
Parallel Tasks и Parallel Stacks. Но так как присвоение идентификаторов происходит 
автоматически, практически невозможно поннтб, какие значешш к каким задангшм 
относлтсл. Тем не менее можно обратитксл к статическому своиству Currentld 
обвекта Task, которое возврагцает значение типа Int32, допускагогцего присвоение 
значении null(Int32?). Узнатв идентификатор кода, отладка которого происходит 
в даннвш момент, можно также в окнах Visual Studio Watch и Immediate. После зтого 
остаетсн наити зто задание в окне Parallel Tasks или Parallel Stacks. Если же запроситв 
CBoiicTBO Currentld длн задашш, которое не вБшолниетсн, возврагцаетсл null. 



766 Глава 27. Асинхронние BbiHnannTeabHbie операции 


УзнатБ, на какои стадии своего жизненного цикла находитсн задание, можно при 
помогци предназначенного толбко длн чтенил своиства Status обЂекта Task. Оно 
возврагцает значение TaskStatus, которое определнетси следугогцим образом: 

public enum TaskStatus { 

// Флаги, обозначаклцие состонние заданил: 

Created, // Задание создано в нвном виде 

// и может 6biTb запуцено вручнут 
WaitingFonActivation, // Задание создано ненвно 

// и запускаетсн автоматически 

WaitingToRun, // Задание запланировано, но еце не запуцено 

Running, // Задание виполнлетсл 

// Задание ждет завершенил дочерних задании, чтобш завершитвсл 
WaitingFonChildnenToComplete, 

// Возможнме окончателвнме состолнил заданил: 

RanToCompletion, 

Canceled, 

Faulted 

} 

Толбко что созданнБги оотјСкт Task имеет статус Created. Позднее, когда зада- 
ние ставитси в очередБ на вБшолнение, его статус мениетсл на WaitingToRun. За- 
пугценному заданиго в потоке присваиваетси статус Running. Приостановленному 
заданиго, которое ожидает завершенгш дочерних задании, соответствует статус 
WaitingForChildrenToComplete. Полностбго завершенное задание ггмеет одно из 
трех возможнбгх состоинии: RanToCompletion, Canceled или Faulted. УзнатБ ре- 
зулБтат вБгполненгш задангш Task<TResult> можно через его своиство Result. Еслгг 
вБгполнение задачи Task илгг Task<TResult> прерБгваетсл, узнатв, какое именно 
необработанное исклгочение 6бгло вброшено, можно через своиство Exception о6б- 
екта Task; оно всегда возврагцает обвект AggregateException, коллекцгш которого 
состоит из необработаннвгх исклгочении. 

Длл удобства обвект Та sk предоставлнет набор предназначеннвгх толбко длл 
чтенггн своиств типа Boolean: IsCanceled, IsFaulted и IsCompleted. Последнее 
своиство возврагцает значение true, еслгг обвект Task находитсл в состоингш 
RanToCompleted, Canceled или Faulted. Определитв, успешно ли вБгполнено за- 
дание, прогце всего при помогци вот такого кода: 

if (task.Status == TaskStatus . RanToCompletion) ... 

Обвект Task оказвгваетсл в состоннии WaitingForActivation, если он созда- 
етсл при помогци однои из следугогцих функции: ContinueWith, ContinueWhenAll, 
ContinueWhenAny гглгг FromAsync. Задание, созданное путем конструированил 
обвекта TaskCompletionSource<TResult>, также оказвгваетсл в состоинии 
WaitingForActivation. Зто состонние означает, что планирование задангш управ- 
лнетсл его собственнои инфраструктурои. К примеру, невозможно нвнбгм образом 
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запуститБ обпект Task, создашњш вбиовом функции ContinueWith. Зто задание 
запуститсл автоматически после завершенип предБвдушего. 


Фабрики задании 

Иногда возникает необходимоств получитБ набор обнектов Task, находлгцихсл 
в одном и том же состоннии. Длл зтого не нужно раз за разом передаватв одни и те 
же параметрБ1 в конструктор каждого заданин, достаточно создатв фабрику заданип 
(task factory), инкапсулиругогцуго нужное состонние. В пространстве имен System . 
Threading.Tasks определенБ 1 тшш TaskFactory и TaskFactory<TResult>. Оба 
зтих типа нвлнготсн производнвши от типа System .Object; то естБ они нвлнготси 
равиора) i говБгми. 

Длн созданил группБ1 задании, не возврагцагогцих значении, конструируетсл 
класс TaskFactory. Если же зти задангш должнбг возврагцатБ некое значение, по- 
требуетсн класс TaskFactory<TResult>, которому в обобгценном аргументе TResult 
передаетсл желаемвпг тип возврагцаемого значенгш. При создании зтих классов 
их конструкторам передаготсн параметрвг, которвгми задангш должнбг обладатБ по 
умолчаниго. А точнее, передаготси параметрнг CancellationToken, TaskScheduler, 
TaskCreationOptions и TaskContinuationOptions, наделнгогцие задангш нужнБши 
своиствами. 

Пример примененгш класса TaskFactory: 

Task parent = new Task(() => { 

varcts = new CancellationTokenSource(); 
vartf = new TaskFactory<Int32>(cts.Tokenj 
TaskCreationOptions.AttachedToParent, 

TaskContinuationOptions.ExecuteSynchronouslyj 
TaskScheduler.Default); 

// Задание создает и запускает 3 дочерних заданил 
varchildTasks = new[] { 

tf.StartNew(() => Sum^cts.Token, 10000)), 
tf.StartNew(() => Sum(cts.Token, 20000)), 

tf.StartNew(() => Sum(cts.Token, Int32.MaxValue)) // Исклк)чение 

// OverflowException 

H 


// Если дочернее задание становитсл источником исклгаченил, 

// отменлем все дочерние заданил 

for (Int32 task = 0; task <childTasks.Length; task++) 
childTasksftask].ContinueWith( 

t => cts.Cancel(), TaskContinuationOptions.OnlyOnFaulted); 

// После завершенил дочерних задании получаем максималБное 
// возврашенное значение и передаем его другому заданик) 

// длл вшвода 
tf.ContinueWhenAll( 
childTasks, 


продолжение & 
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completedTasks => completedTasks.Where( 

t => It.IsFaulted && !t.IsCanceled).Max(t => t.Result), 

CancellationToken.None) 

.ContinueWith(t =>Console.WriteLine("The maximum is: " + t.Result), 
TaskContinuationOptions.ExecuteSynchronously); 

}); 

// После завершенип дочерних задании вшводим, 

// в том числе, и необработаннме искличенин 
parent.ContinueWith(p => { 

// Текст помецен в StringBuilder и однократно вмзван 
// метод Console.WriteLine просто потому, что зто задание 
// может BbinonHRTbcfl параллелино с предшдуцим, 

// и н не хочу путаницш в вшводимом резулитате 
StringBuildersb = new StringBuilder( 

"The following exception(s) occurred:" + Environment.NewLine); 

foreach (var e in p.Exception.Flatten().InnerExceptions) 
sb.AppendLine(" "+ e.GetType() .ToStringO); 

Console.WriteLine(sb.ToString()); 

}, TaskContinuationOptions.OnlyOnFaulted); 

// Запуск родителцского заданип, которое может запускатц дочерние 
parent.Start(); 

В зтом коде создаетсл обкект TaskFactory<Int32>, при помоти которого потом 
создаготсл три обгекта Task. При отом н хочу, чтобм все обвектм Task обладали 
одним и тем же маркером CancellationTokenSource, чтобм все они имели одного 
родителн, чтобм длн них всех исполБЗОвалсн один и тот же заданнми по умолчаниго 
планировгцик задании и чтобм все они вмполннлисб одновременно. 

Позтому из трехобвектов Task, созданнмх методом StartNewKHaccaTaskFactory, 
формируетсн массив. Даннми метод краине удобен длл создангш и запуска дочерних 
задании. В цикле каждое из дочерних задании, ставшее источником необработан- 
ного исклгочешш, отменнет все осталБнме запугценнме в даннми момент задангш. 
Напоследок в классе TaskFactory вмзмваетсн метод ContinueWhenAll, создагогции 
задание, вмполннгогцеесл после завершенгш всех дочерних задании. Будучи создано 
в классе TaskFactory, зто новое задание также считаетсл дочерним и вмполннетсл 
в синхронном режиме с помогцбго заданного по умолчаниго планировгцика. Но так 
как оно должно вбшолнлтбсл даже после отменм осталБнмх дочерних задании, 
его своиство CancellationToken переопределлетсл путем передачи ему значенгш 
CancellationToken . None. Зто вообгце исклгочает возможностб отменБг заданин. 
Ну и после того, как обрабатБшагогцее резулБтатБг задание завершает свого работу, 
создастсм егце одно задание, предназначенное длл ввгвода максималБного из воз- 
врагценнБгх дочерними задангшми значенгш. 
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ПРИМЕЧАНИЕ 

Bbi30B статических методов ContinueWhenAII и ContinueWhenAny классов 
TaskFactory или TaskFactory<TResult> делает недеиствителвнв 1 ми следукзидие фла- 
ги TaskContinuationOption: NotOnRanToCompletion, NotOnFaulted и NotOnCanceled. 
Игнорирукзтсл и такие вспомогателвнме флаги, как OnlyOnCanceled, OnlyOnFaulted 
и OnlyOnRanToCompletion. То ecTb методм ContinueWhenAII и ContinueWhenAny за- 
пускакзт следукзидее задание вне зависимости оттого, каким оказмваетсл резулетат 
ввшолненил предв 1 дуцдего. 


Планиров1дики задании 

Заданил обладагот оченд гибкои инфраструктурои, причем не в последнгого очередБ 
благодарн обвектам TaskScheduler. Именно обвект TaskScheduler отвечает за 
вБшолнение запланированнБгх задании и вбшоднт информациго о них в отладчике 
Visual Studio. В FCL сушествует два производнћгх от TaskScheduler типа: плаии- 
ровгцик задании в пуле потоков и планировгцик задании контекста синхрониза- 
ции. По умолчаниго все приложенгш исполБзугот первћш из них, планиругогции 
заданин рабочих потоков в пуле (он подробно рассматриваетсн чутБ позже). Длн 
полученгш ссБглки на него исполБзуетсн статическое своиство Def ault класса 
TaskScheduler. 

Планировгцики задании контекста синхронизации обвгчно применнготсн в при- 
ложенгшх Windows Forms, Windows Presentation Foundation (WPF), Silverlight 
и Windows Store. Они планиругот задангш в потоке графического интерфеиса при- 
ложенгш, обеспечиван оперативное обновление таких злементов интерфеиса, как 
кнопки, пунктвг менго и т. п. Зтот планировгцик вообгце никак не исполвзует пул 
потоков. ПолучитБ на него ссиглку можно с помогцбго статического метода From- 
CurrentSynchronizationContext класса TaskScheduler. 

Следугогцее простое ириложение Windows Forms демонстрирует ирименение 
планировгцика задании контекста синхронизации: 

internal sealed class MyForm : Form { 

private readonly TaskScheduler m_syncContextTaskScheduler; 
public MyForm() { 

m_syncContextTaskScheduler = 

TaskScheduler.FromCurrentSynchronizationContext(); 

Text = "Synchronization Context Task Scheduler Demo"; 

Visible = true; Width = 600; Fleight = 100; 

} 

// Получение ссмлки на планировтик задании 

private readonly TaskScheduler m_syncContextTaskScheduler = 

TaskScheduler.FromCurrentSynchronizationContext(); 

private CancellationTokenSource m_cts; 

protected override void OnMouseClick(MouseEventArgs e) { 

продолжение & 
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if (m_cts != null) { // Операциа начата, отменнем ее 
m_cts.Cancel(); 
m_cts = null; 

} else { // Операцин не начатаЈ начинаем ее 

Text = "Openation nunning"; 
m_cts = new CancellationTokenSounce(); 

// Задание исполвзует планировцик по умолчанив 
// и внполнлет поток из пула 

Task<Int32> t = Task.Run(() => Sum(m_cts.Token, 20000), m_cts.Token); 

// Зти заданил исполцзук)т планировцик контекста синхронизации 
// и вмполнл 1 отсл в потоке графического интерфеиса 
t.ContinueWith(task => Text = "Result: " + task.Result, 

CancellationToken.None, 

TaskContinuationOptions.OnlyOnRanToCompletion, 
m_syncC°ntextTaskSchedulen); 

t.ContinueWith(task => Text = "Openation canceled", 

CancellationToken.None, TaskContinuationOptions.OnlyOnCanceled, 
m_syncContextTaskSchedulen); 

t.ContinueWith(task => Text = "Openation faulted", 

CancellationToken.None, TaskContinuationOptions.OnlyOnFaulted, 
m_syncC°ntextTaskSchedulen); 

} 

base.OnMouseClick(e); 

} 

} 

При шелчке на клиентскои области даннои формм в потоке пула начинает 
вмполнитбсл ввшислителБное задание. Зто хорошо, так как означает, что GUI- 
поток не заблокирован и может реагироватв на операции с полБЗОвателБСКим 
интерфеисом. При зтом исполннемБш потоком из пула код не должен пБматБСл 
обновлитБ злементБ1 интерфеиса. В противном случае будет вввдано исклгочение 
InvalidOperationException. 

После завершенин заданин, свнзанного с вБшисленгшми, начинает вбшолннтбсн 
одно из трех следугогцих за ним задании. Все зти задангш обрабатишаготси плани- 
ровгциком контекста синхронизации, причем зтот планировгцик ставит заданин 
в очередв GUI -потока, позволнн коду зтих задании успешно обновлнтв злементБ1 
интерфеиса. Обновление подписеи на форме осугцествлнетсл через унаследованное 
своиство Text. 

Так как вБшислителвное задание (метод Sum) запускаетсн в потоке пула, полвзова- 
телв может отменитБ операции при помогци злементов интерфеиса. В моем примере 
дли отменБ1 операции достаточно гцелкнутБ на клиентскои области формБк 

Разумеетсл, при наличии специалБНБ 1 х требовании к планировгцику можно 
определитвсобственнБш класс, производнБпгот TaskScheduler. Microsoft предлагает 
множество примеров кода длл задании и различнБ 1 х планировгциков в пакете Parallel 
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Extensions Extras, которми можно загрузитћ по адресу http://code.msdn. microsoft. 
com/ParExtSamples. Там вм наидете, в частности, следукдцие планировгцики: 

□ IOTaskScheduler. Ставит задангм в очередБ в потоках ввода-вБшода пула, а не 
в рабочих потоках. 

□ LimitedConcurrencyLevelTaskScheduler. Позволнет одновременно вбшолннтбсл 
не более чем n заданилм, где n — параметр конструктора. 

□ OrderedTaskScheduler. Разрешает вБшолнение толбко одного заданин за раз. 
ДаннБш класс ивлнетсн производнћш от LimitedConcurnencyLevelTaskSched 
ulen и в качестве параметра n ему передаетсл 1 . 

□ PrioritizingTaskScheduler. Ставит задашш в очередв в пуле потоков средБ 1 CLR. 
После зтого можно вБИватБ метод Pnionitize и указатБ, что задание должно 
6б1тб обработано раннше всех осталвнБ1х задании (если зто егце не сделано). 
Метод Depnionitize, соответственно, позволнет вбшолнитб задание после всех 
прочих. 

□ ThreadPerTaskScheduler. Создает и запускает отделБнвш поток длл каждого 
задангш, при зтом пул потоков не исполвзуетсн. 


МетодБ! For, ForEach и Invoke класса Parallel 

Сугцествугот стандартнвге ситуации, в которвгх теоретически возможно поввгше- 
ние производителБности, обусловленное применением задании. Длл упрогценин 
программированин зти сценарии инкапсулированБг в статическии класс System. 
Thneading.Tasks . Panallel. Например: 

// Один поток виполниет воо работу последователБно 
for (Int32 i = 0; i < 1000; i++) DoWork(i); 

Вместо обработки всех злементов зтои коллекции можно восполБЗОватБСи ме- 
тодом Fon класса Panallel и распределитБ работу между несколБКими потоками 
из пула: 

// Потоки из пула виполнлкгт работу параллелБно 
Parallel . For(0, 1000, i => DoWork(i)); 

АналогичнБгм образом следугогцуго конструкциго: 

// Один поток виполнлет вск) работу по очереди 
foreach (var item in collection) DoWork(item); 

можно заменитБ такои: 

// Потоки из пула виполнлтт работу параллелчно 
Parallel . ForEach(collection, item => DoWork(item)); 
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Если у вас естБ Bbi6op между Fon и ForEach, лучше исполћзуите цикл For, так 
как он работает бмстрее. 

Если вам нужно вбшолнитб несколБКО методов, можно сделатБ зто последова- 
телБно — например, вот так: 

// Один поток внполнлет методн по очереди 
Methodl( ); 

Method2( ); 

Method3( ); 

Также возможно параллелБное вБшолнение: 

// Потоки из пула внполнлнзт методн одновременно 
Parallel . Invoke( 

() => Methodl(), 

() => Method2(), 

() => Method3()); 

Bce методБ 1 класса Ра rallel заставлнгот m>i3i>ii!aioiniiii потокприниматБучастие 
в их обработке. Зто хорошо с точки зренин расходованин ресурсов, так как вБ13Б1ва- 
јошии поток не блокируетсл, ожидан вБшолненин работБ 1 потоками пула. Впрочем, 
если вБшолнение вБ13Б1вак>шего потока будет закончено до того, как потоки из пула 
вбшолннт свок) частБ, вБ13Б1вак>гции поток приостанавливаетсл до их завершенин, 
что тоже неплохо, так как обеспечивает семантику, аналогичнуго применениго 
цикла for или foreach. ВБшолнение вБИБшагогцего потока не возобновлнетсн, пока 
не будет завершена вси работа. Если какан-либо операции станет источником не- 
обработанного исклгочешш, вБ13ваннБш вами метод Parallel вБвдаст исклгочение 
AggregateException. 

Разумеетсн, зто не значит, что все циклб 1 f or в своем коде следует заменитБ Bbi- 
зовами Parallel . For, а циклб 1 foreach — вБ130вами Parallel . ForEach. Bbi30Bbi 
Parallel базируготсн на предположении, что рабочие злементБ 1 без проблем смогут 
вбшолнптбсл параллелБно. Значит, длл задании, которБШ должнб 1 вбшолнитбсл 
последователБно, вбгоов зтого метода не имеет смБ 1 сла. Следует также избегатБ ра- 
бочих злементов, вноснгцих измененгш в лгобБге совместно исполБзуемБге даннБге, 
так как при одновременном управлении несколБкими потоками зти даннБге могут 
оказатБСн поврежденнБши. 06бшно зта проблема решаетсн в рамках синхронизации 
потоков блокированием фрагментов кода, в которБгх реализуетсл доступ к даннБш. 
Однако так как после зтого доступ к ддннбш в каждБш момент времени сможет по- 
лучатБ толбко один поток, териетсл преимугцество одновременного обслуживангш 
множества злементов. 

Кроме того, методБг класса Parallel потреблнгот много ресурсов — приходитсн 
вБгделлтБ памнтБ под делегатБг, которБге вБгзБшаготсл по одному длл каждого рабочего 
алемента. При наличгш множества рабочих злементов, которБге могут обслуживатБ- 
сл разнБши потоками, можно получитБ рост производителБности. К тому же если 
каждБш злемент вБшолннет много работБг, на снижение производителБности из-за 
вБгзова делегатов можно не обрагцатБ внимангш. ПроблемБ! начинаготсн в случае, 



Методи For, ForEach и Invoke класса Parallel 773 


когда методм класса Parallel применаготсн к неболБшому числу рабочих злементов 
или же к злементам, обслуживание котормх происходит оченв бмстро. 

Следует упомннутБ, что длл методов For, ForEach и Invoke класса Parallel 
сугцествугот перегруженнме версии, принимагогцие обвект ParallelOptions. Вот 
как он вмгллдит: 

public class ParallelOptions{ 
public ParallelOptions(); 

// Допускает отмену операции 

public CancellationTokenCancellationToken { get; set; } 

// По умолчанин) CancellationToken. None 

// Позволлет задатц максималцное количество рабочих 

// злементов, вмполннеммх одновременно 

public Int32MaxDegreeOfParallelism { get; set; } 

// По умолчанига -1 (число доступних процессоров) 

// Позволлет вибратц планировтика задании 
public TaskSchedulerTaskScheduler { get; set; } 

// По умолчанин) TaskScheduler.Default 

} 


Сугцествугот перегруженнме версии и длн методов FornForEach, позволнгогцие 
передаватБ три делегата: 

□ Делегат локалБнои инициализации задании (locallnit) длн каждои вмпол- 
ниемои задачи вмзмваетсл толбко один раз — перед получением командм на 
обслуживание рабочего злемента. 

□ Делегат body вмзмваетсл один раз дли каждого злемента, обслуживаемого уча- 
ствугогцими в процессе потоками. 

□ Делегат локалБного состоишш каждого потока (localFinally) вмзмваетсл 
один раз длн каждого заданин, после того как оно обслужит все переданнме ему 
рабочие злементм. Также он вмзмваетсл, если код делегата body становитсл ис- 
точником необработанного исклгочешш. 

Следугогции пример кода демонстрирует исполг>зование зтих трех делегатов на 
примере суммировангш баитов длл всех фаилов, содержагцихсл в каталоге: 

private static Int64 DirectoryBytes(String path, String searchPattern, 

SearchOptionsearchOption) { 

var files = Directory.EnumerateFiles(path, searchPattern, searchOption); 

Int64 masterTotal = 0; 

ParallelLoopResult result = Parallel.ForEach<String, Int64>( 
files, 

()=>{// locallnit: вмзмваетсА в момент запуска заданин 

продолжение # 



774 Глава 27. Асинхронние BbiHnannTeabHbie операции 


// Инициализацил: задача обработала 0 баитов 

return 0; // Присваивает taskLocalTotal началцное значение 0 

L 


(filej loopState, indexj taskLocalTotal) => { // body: Внзмваетсл 

// один раз длл каждого злемента 
// Получает размер фаила и добавллет его к обцему размеру 
Int64 fileLength = 0; 

FileStreamfs = null; 
try { 

fs = File.OpenRead(file); 
fileLength = fs.Length; 

} 

catch (IOException) { /* Игнорируем фаилм, к котормм нет доступа */ } 
finally { if (fs != null) fs.Dispose(); } 
return taskLocalTotal + fileLength; 

}, 


taskLocalTotal => { // localFinally: Внзмваетсл один раз в конце заданил 
// Атомарное прибавление размера из заданил к обцему размеру 
Interlocked.Add(ref masterTotal, taskLocalTotal) ; 

}); 

return masterTotal; 

} 

Каждое задание управлнет собственнои промежуточнои суммои (в переменнои 
taskLocalTotal) длл даннмх еи фаилов. После того как все заданин завершатсл, 
в безопасном в отношении потоков режиме обновлнетсл обгцаи сумма. Дли зтого 
исполБзуетсл метод Interlocked .Add (подробно он рассматриваетсл в главе 28). 
Так как промежуточнаи сумма длл каждого заданин своч, во времл обработки зле- 
ментов не требуетсн синхронизацин потоков, которан отрицателБно сказмваетсн на 
производителБности. Они возникакзт толбко на последнем зтапе при вмзове метода 
Interlocked . Add. То естБ снижение производителБности происходит единовременно 
дли задангш, а не длл рабочего злемента. 

Веронтно, вб 1 обратили внимание, что делегату body передаетсл обвект 
ParallelLoopState: 

public class ParallelLoopState{ 
public void Stop(); 
public BooleanlsStopped { get; } 

public void Break(); 

public Int64? LowestBreakIteration{ get; } 

public BooleanIsExceptional { get; } 

public BooleanShouldExitCurrentIteration { get; } 

} 

Каждое принимакзгцее участие в работе задание получает собственнвш обвект 
ParallelLoopState и исполкзует его длн взаимодеиствгш с другими работагогцими 
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заданинми. Метод Stop останавливает цикл, и все будутцие запросм к своиству 
IsStopped возврашагот значение true. Метод Break заставлиет цикл отказатћси от 
обработки всех злементов, расположеннмх после вмделенного. Предположим, что 
цикл ForEach должен обработатБ 100 злементов, но после обработки пнтого зле- 
мента 6бш вБ13ван метод Break. В итоге цикл гарантированно обрабатвшает первБ 1 е 
пнтб злементов и возврагцает управление. Впрочем, зто не исклгочает обработки 
дополнителБНБ 1 хзлемеитов. Своиство LowestBreakIteration возврагцает низшуго 
итерацшо цикла, на которои 6бш вБИван метод Break. Если зтот метод вообгце не 
вБИвалсн, своиство возврагцает значение null. 

Своиство IsException возврагцает true, если при обработке хотл 6 bi одного 
злемента 6 бшо вброшено необработанное исклгочение. Если обработка занимает 
много времени, ваш код может обратитвсн к своиству ShouldExitCurrentIteration, 
что 6 б 1 узнатБ, не нужно ли прерватБ текугцуго итерациго цикла. Своиство воз- 
врагцает значение true, если 6бш вБИван метод Stop или Break, отменен обвект 
CancellationTokenSource (ссвшка на него даетсн через своиство CancellationToken 
класса ParallelOption) или же обработка злемента привела к необработанному 
исклгочениго. 

МетодБ 1 For и ForEach класса Parallel возврашагот зкземплнр ParallelLoop- 
Result, которвп! вбшллдит так: 

public struct ParallelLoopResult{ 

// Воввра 1 цает false в случае преждевременного завершенин операции 
public Boolean IsCompleted { get; } 
public Int64? LowestBreakIteration{ get; } 

} 

РезулБтат работБ 1 цикла можно определитк при помоши своиств. Если своиство 
IsCompleted возврашает значение true, значит, цикл проиден полностбго, и все 
злементБ 1 обработанБк Если своиство IsCompleted возврашает значение false, 
а CBOiicTBO LowestBreakIteration — значение null, значит, каким-то из потоков 6бш 
вБ13ван метод Stop. Если же в последнем случае значение, возврагцаемое своиством 
LowestBreakIteration, отлично от null, значит, каким-то из потоков 6бш вБ13ван 
метод Break. При зтом возврашенное своиством LowestBreakIteration значение 
типа Int64 указБ 1 вает индекс последнего гарантированно обработанного алемента. 
Длн корректного восетановлешш в случае вввдачи исклгоченин следует перехватитБ 
AggregateException. 


ВстроеннБш лзб1к параллелБннх запросов 

РазработаннБп! Microsoft встроеннБш нзбш запросов (Language Integrated Query, 
LINQ) предлагает удобнвш синтаксис запросов к даннвш. С его помогцвго зле- 
ментБ1 легко филктроватБ и сортироватБ, возврашатБ спроецированнБ1е наборБ1 
злементов и делатв многое другое. При работе с обвектами все злементв! в на- 
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боре даннмх последователБно обрабатв1вак>тсл одним потоком — ото назБ1ваетсл 
последователЂНЂш запросом (sequential query). Повб1Ситб производителБностБ 
можно при помош,и изБ1ка параллелБНБ1х запросов (Parallel LINQ), позволлгош,его 
последователБНБш запрос превратитБ в параллелЂнип (parallel query). Последнии 
во внутреннеи реализации задеиствует заданил (поставленнБ 1 е в очередв пла- 
нировшиком, исполвзуемБ 1 м по умолчаншо), распределлл злемептБ 1 коллекции 
среди несколБких процессоров длл обработки. Как и в случае с методами класса 
Parallel, максималБНБпг вБшгрБшг достигаетси при наличии множество злемен- 
тов длл обработки или когда обработка каждого злемента представллет собои 
длителБнуго вБ 1 числителБнук> операцшо. 

Всн функционалБностБ Parallel LINO реализонлпав статическомклассе System . 
Linq . ParallelEnumerable (он определенвбиблиотеке System.Core.dll), позтому 
в код следует импортироватв пространство имен System. Linq. В частности, зтот 
класс содержит параллелБНБШ версии всех стандартнБ1х LINQ-onepaTopoB, таких 
как Where, Select, SelectMany, GroupBy, 3oin, OrderBy, Skip, Take и т. п. Bce зти 
методБ1 нвлнготсн методами расширенин типа System . Linq . Ра rallelQuery<T>. Длн 
вБшова их параллелБНБ 1 х версии следует преобразоватв последователБНБпг запрос 
(основаннБш на интерфеисе IEnumerable или IEnumerable<T>) в параллелвнБпг 
(основаннБпг на классе ParallelQuery или ParallelQuery<T>), восполБЗОвавшисБ 
методом расширенгш AsParallel класса ParallelEnumerable, которкп! вбплндит 
следугошим образом 1 : 

public static ParallelQuery<TSource> AsParallel<TSource>( 
this IEnumerable<TSource> source) 
public static ParallelQuery AsParallel(this IEnumerablesource) 

Вот пример преобразованин последователвного запроса в параллелБНБ1и. Он 
возврагцает все устаревшие методБ 1 , определеннБШ в сборке: 

private static void ObsoleteMethods(Assembly assembly) { 
var query = 

from type in assembly.GetExportedTypes().AsParallel() 

from method in type.GetMethods(BindingFlags.Public | 

BindingFlags.Instance | BindingFlags.Static) 

let obsoleteAttrType = typeof(ObsoleteAttribute) 

where Attribute.IsDefined(method л obsoleteAttrType) 

orderbytype.FullName 

let obsoleteAttrObj = (ObsoleteAttribute) 

Attribute.GetCustomAttribute(method, obsoleteAttrType) 

select String.Format("Type={0}\nMethod={l}\nMessage={2}\n", 


l 


Класс ParallelQuery<T> лвллетсл производнБШ от ParallelQuery. 
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type . FullNamej method.ToStringO, obsoleteAttrObj .Message); 

// Внвод резулвтатов 

foreach (var result in query) Console.WriteLine(result); 

} 

Хотн подобнме решенин не типичнм, также сушествует возможностб в ходе опе- 
рации переклгочитБСн с параллелБного режима на последователБНБш. Зто делаетсл 
при помоши метода AsSequential класса ParallelEnumerable: 

public static IEnumerable<TSource> AsSequential<TSource>( 

this ParallelQuery<TSource> source) 

Зтот метод преобразует ParallelQuery<T> в интерфеис IEnumerable<T>, и все 
операции начинагот вбшолннтбсн всего одним потоком. 

Обвшно резулБтат LINQ-3anpoca вБ 1 числлетсл потоком, исполпмкнцпм ин- 
струкцшо foreach (как 6бшо показано ранее). Зто означает, что все резулвтатБ 1 
запроса просматривакзтсл всего одним потоком. ПараллелвнБш режим обработки 
обеспечивает метод ForAll класса ParallelEnumerable: 

static void ForAll<TSource>( 

this ParallelQuery<TSource> source, Action<TSource> action) 

Зтот метод позволлет несколвким потокам одновременно обрабатвшатв ре- 
зулБтатБ1 запросов. Мои приведеннБп) ранее код с помогцбкз зтого метода можно 
переписатБ следугогцим образом: 

// BbiBOA резулБтатов 

query . ForAll(Console.WriteLine) ; 

Однако одновременнБпл вбгоов метода Console . WriteLine несколБкими потоками 
отрицателБно сказБшаетсн на производителБности, так как класс Console внутренне 
синхронизирует потоки, гарантирун, что к консоли в каждвш момент времени имеет 
доступ толбко один поток. Именно зто предотврагцает смешение ввшода потоков, 
из-за которого может понвитбсн непоннтнБш резулБтат. ИсполБзуите метод ForAll 
в случанх, когда требуетсн вБгчисление каждого из резулБтатов. 

Так как при параллелвном LINQ-3anpoce злементБг обрабатБшаготсп несколБ- 
кими потоками одновременно, резулвтатБг возврагцаготсл в произволвном порндке. 
Длн сохраненгш очередности обработки злементов применнетсн метод AsOrdered 
класса ParallelEnumerable. С его помогцбго потоки разбивагот злементБг по груп- 
пам, которпге впоследствгш сливаготсн друг с другом. Однако все зто отрицателвно 
сказБшаетсл на производителБности. Вот операторБг, предназначеннБге длл вбг- 
полненгш неупорлдоченнБгх операцгш: Distinct, Except, Intersect, Union, loin, 
GroupBy, Grouploin и ToLookup. После лгобого из зтих операторов можно ввгзватБ 
метод AsOrdered, что6бг упорндочитБ злементБг. 

Следугогцие операторБг вбгполнпгот упорлдоченнБге операции: OrderBy, 
OrderByDescending, ThenBy и ThenByDescending. Если вбг хотите вернутБСл к не- 
упорндоченнБш операцгшм, что6бг повбгситб производителБностБ, после лгобого из 
зтих операторов также можно ввгзватБ метод AsUnordered. 
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Parallel LINO гакже предоставлиет дополнителмгме методм класса Parallel- 
Enumerable, позволпкнцие управлнтБ обработкои запросов: 

public static ParallelQuery<TSource> WithCancellation<TSource>( 

this ParallelQuery<TSource> source, CancellationToken cancellationToken) 

public static ParallelQuery<TSource> WithDegreeOfParallelism<TSource>( 
this ParallelQuery<TSource> source, Int32 degreeOfParallelism) 

public static ParallelQuery<TSource> WithExecutionMode<TSource>( 

this ParallelQuery<TSource> source, ParallelExecutionMode executionMode) 

public static ParallelQuery<TSource> WithMergeOptions<TSource>( 

this ParallelQuery<TSource> source, ParallelMergeOptions mergeOptions) 

Очевидно, что методу WithCancellation можно передатБ обвект Cancellation- 
Token, что дает возможностб в лгобои момент остановитБ обработку запроса. Метод 
WithDegreeOfParallelism задает максималБное количество потоков, которвш мо- 
гут обрабатвшатБ запрос; при зтом, если количество реалвно необходимБ1х потоков 
менБше указанного, новбш потоки не создаготсн. 06бшно зтот метод не исполБзуетсл, 
и по умолчаншо запрос исполннетсл одним потоком на одно лдро. Однако зтот 
метод можно вБШватБ, указав число ндер, менвшее реалБно имекнцсгоси, оставив 
частв ндер дли решенин других задач. Если запрос вБшолннет синхроннуго опера- 
niiio ввода-вБгвода, можно указатн число лдер, iipeiii.niiaioiuec реалБно имегогцеесл, 
так как во времн таких операции потоки блокируготси. При таком подходе потоки 
исполБзуготсл незффективно, зато вбг бБгстрее получаете резулнтат. Зто можно 
делатБ в клиентских приложениих, но н 6 бг краине не рекомендовал прибегатв 
к синхроннБгм операциим ввода-вБшода в сервернвгх приложенинх. 

Parallel LINQ анализирует запрос и внгбирает оптималБНБги способ его об- 
работки. Иногда производителБностБ может оказатБСи вБгше при последова- 
телвнБгх запросах. 06бшно зто бнгвает при исполБЗОвании следугогцих операции: 
Concat, ElementAt(OrDefault), First(OrDefault),Last(OrDefault),Skip(While), 
Take(While) или Zip. Кроме того, зто верно длн случаев исполБЗОвашш перегру- 
женнвгх версии методов Select (Мапу) или Where, в которвгх селектору передаетси 
позиционнбш индекс или делегат, возврагцагогции логгшеское значение. При зтом 
запрос можно принудителБно обработатн в параллелвном режиме, передав методу 
WithExecutionMode один из флагов ParallelExecutionMode: 

public enum ParallelExecutionMode { 

Default = 0j // Способ обработки запроса вубираетсл автоматически 

ForceParallelism = 1 // Запрос обрабатуваетсв в параллелБном режиме 

} 

Как уже упоминалосв, в Parallel LINQ, обработкои запросов занимаетсл це- 
лан группа потоков, а значит, возникает необходимоств соединешш получен- 
нбгх резулБтатов в один. Длл управленгш буферизациеи и слиннием злементов 
исполБзуетсн метод WithMergeOptions, которому передаетсл один из флагов 

ParallelMergeOptions: 
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public enum ParallelMergeOptions { 

Default = 0, // Аналогично AutoBuffered (в будуцем может изменитвсл) 

NotBuffered = 1, 11 Резулвтати обрабатмвак)тсл по мере готовности 

AutoBuffered = 2, // Поток буферизует некоторме резулита™ 

// перед обработкои 

FullyBuffered = 3 // Поток буферизует все резулвтати перед обработкои 

} 

По сути, зти параметрм позволинзт вмбратБ желаемое соотношение скорости 
работм и потребленин памлти. Флаг NotBuffered зкономит памнтБ, но обработка 
злементов происходит медленнее. А вот флаг FullyBuffered увеличивает потре- 
бление памлти, но резулшат вм получите бмстрее. Компромиссом между зтими 
вариантами нвлнетсл флаг AutoBuffered. ОпределитБ, какои именно вариант лучше 
всего подходит именно вам, прогце всего зксперименталБнмм путем. Можно также 
приннтБ параметрБр предлагаемБШ по умолчаншо, что оптималнно длл болБшин- 
ства ситуации. ДополнителБнук) информацшо о Parallel LINQ можно наити по 
следугошим адресам: 

□ http://blogs.msdn.com/pfxteam/archive/2009/05/28/9648672.aspx; 

□ http://blogs.msdn.com/pfxteam/archive/2009/06/13/9741072.aspx. 


Периодические вБ1числителБНБ1е операции 

В пространстве имен System .Threading определен класс Timer, которвш позволнет 
периодически вБгзвшатБ методБг из пула потоков. Создаван зкземплнр зтого класса, 
вб 1 сообгцаете пулу, что вам нужен метод, обратнвш вбгзов которого должен 6бгтб 
вБшолнен в заданное времл. У класса Timer еств несколБКО оченк похожих друг на 
друга конструкторов: 

public sealed class Timer : MarshalByRefObject, IDisposable { 
public Timer(TimerCallback callback, Object state, 

Int32 dueTime, Int32 period); 
public Timer(TimerCallback callback, Object state, 

UInt32 dueTime, UInt32 period); 
public Timer(TimerCallback callback, Object state, 

Int64 dueTime, Int64 period); 
public Timer(TimerCallback callback, Object state, 

Timespan dueTime, TimeSpan period); 

} 

Bce и конструкторвг создагот обвект Т imer. Параметр callback указкшает ими 
метода, обратнБ1и вбгоов которого должен вбшолнитбси потоком из пула. Конечно, 
созданнБш метод обратного вБ 130 ва должен соответствоватв типу делегата Sy stem . 
Threading.TimerCallback, которБП! определнетсл следугошимобразом: 

delegate void TimerCallback(Object state); 
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Параметр state конструктора служит длл передачи методу обратного вмзова 
даннмхсостолнин; если зти даннме отсутствугот, передаетсн null. Параметр dueTime 
позволнет задатБ длл CLR времн ожидании (в миллисекундах) перед первмм вмзо- 
вом метода обратного вмзова. Зто времи представлнетси 32-разриднмм значением 
со знаком или без, 64-разриднмм значением со знаком или значением TimeSpan. 
Чтобм метод обратного вмзова активизировалсн немедленно, передаите в пара- 
метре dueTime значение 0. Последнии параметр peniod указмвает периодичностБ 
(в миллисекундах) последугогцих обрагцении к методу обратного вћгзова. Если ему 
передано значение Timeout.Infinite(-l), поток из пула ограничитси одним об- 
рагцением к методу обратного вћгзова. 

В пуле имеетсн всего один поток длн всех обЂектов Т imer. Именно он знает времн 
активизации следугогцего таимера. В зтот момент поток пробуждаетси и вБгзћшает 
метод QueueUserWorkItem обвекта ThreadPool, что6бг добавитБ в очередв пула по- 
токов злемент, активизиругогции метод обратного ввгзова. Если ввшолнение метода 
занимает много времени, возможно повторное срабатвгвание таимера. В резулнтате 
один метод будет вбшолнитбси несколБКими потоками пула. РешитБ зту пробле- 
му можно при помогци таимера, параметру period которого присвоено значение 
Timeout . Infinite. Такои таимер срабатвгвает толбко один раз. Затем в рамках 
метода обратного ввгзова вБгзвшаетсн метод Change и указБшаетси новое времи за- 
держки, а параметру period снова присваиваетси значение Timeout . Infinite. Вот 
как вБггллднт перегруженнБге версии метода Change: 


public sealed class Timer : MarshalByRefObject л IDisposable { 
public Boolean Change(Int32 dueTime, Int32 period); 
public Boolean Change(UInt32 dueTime., UInt32 period); 
public Boolean Change(Int64 dueTime, Int64 period); 
public Boolean Change(TimeSpan dueTime, TimeSpan period); 


Класс Timer содержит также метод Dispose, позволнгогции вообгце отклгочатБ 
таимер и при желании при помогци параметра notifyObject сообгцатБ идру о за- 
вершении всех ожидагогцих обратнвгх вбгзовов. Вот как вбгглндлт перегруженнБге 
версии метода Dispose: 


public sealed class Timer : MarshalByRefObject, IDisposable { 
public Boolean Dispose(); 

public Boolean Dispose(WaitHandle notifyObject); 

} 


ВНИМАНИЕ 

При утилизации обБектаЋтегуборидиком мусора поток пулаостанавливаеттаимер, 
чтобм он болБше не срабатмвал. Позтому при работе с таимером следует прове- 
рнтБ наличие переменнои, поддерживакз 1 цеи его суидествование, иначе обраиденин 
к методу обратного вмзова прекратнтсн. Зта ситуацил подробно обсуждаласи 
в главе 21. 
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В следукицем коде поток из пула вмзмвает метод, которми сначала вмполннетсн 
немедленно, а затем через каждме две секундм. 

internal static class TimerDemo { 
private static Timer s_timer; 

public static void Main() { 

Console.WriteLine("Checking status every 2 seconds"); 

// Создание таимера, которми никогда не срабатнвает. Зто гарантирует, 

// что сшлка на него будет хранитнсл в s_timer, 

// До активизации Status потоком из пула 

s_timer = new Timer(Status, null, Timeout.Infinite, Timeout.Infinite); 

// Tenepb, когда s_timer присвоено значение, можно разрешити таимеру 
// срабатмватц; mn знаем, что вмзов Change в Status не вшдаст 
// исклтчение NullReferenceException 
s_timer.Change(0, Timeout.Infinite); 

Console.ReadLine(); // Предотврацение завершенил процесса 

} 

// Сигнатура зтого метода должна соответствоватц 
// сигнатуре делегата TimerCallback 
private static void Status(Object state) { 

// Зтот метод вшполнлетсл потоком из пула 
Console.WriteLine("In Status at {0}", DateTime.Now); 

Thread.Sleep(1000); // Имитацил другои работш (1 секунда) 

// Заставллем таимер снова вшзватц метод через 2 секундш 
s_timer . Change(200@, Timeout . Infinite) ; 

// Когда метод возврацает управление, поток 
// возврацаетсл в пул и ожидает следукпцего заданил 

} 


Длн периодического вмполненин операции также возможен другои вариант 
организации кода — с исполБЗОванием статического метода Delay класса Task в со- 
четании с клгочевБши словами C# async и await (см. главу 28). Ниже приведена 
переработаннан версин предБвдушего кода: 

internal static class DelayDemo { 
public static void Main() { 

Console.WriteLine("Checking status every 2 seconds"); 

Status(); 

Console.ReadLine(); // Предотврацение завершенил процесса 

} 

// Методу можно передаватц лшбше параметрш на ваше усмотрение 
private static async void Status() { 
while (true) { 


продолжение & 
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Console.WriteLine("Checking status at {0 }", DateTime.Now); 

// Здесв размецаетса код проверки состовнив... 

// В конце цикла создаетсн 2-секунднан задержка без блокировки потока 
await Task.Delay(2000); // await ожидает возвра!ценин управленив потоком 

} 

} 

} 

Разновидности таимеров 

Библиотека FCL содержит различнме таимерм, но болБшинство программистов 

даже не знагот, чем они отличаготсн друг от друга. 

□ Класс Timer из пространства имен System.Threading. Зтот класс рассматри- 
валсч в предмдугцем разделе. Он лучше других подходит длч вмполненгш по- 
вторнгогцихсч фоновмх задании с потоками пула. 

□ Класс Timer из пространства имен System.Windows.Forms. Создание зк- 
земплнра зтого класса указмвает Windows на необходимостг> свизатБ таимер 
с вБИБшагогцим потоком (см. Win32u:})y шти io SetTimen). При срабатБшании 
таимера Windows добавлиет в очередв сообгцении потока сообгцение таимера 
(WM_TIMER). Поток должен извлечк зти сообгценгш и передатн ихнужному методу 
обратного вБгзова. Обратите внимание, что всн работа осугцествлиетсл одним 
потоком — устанавливает таимер тот же поток, которвш исполнчет метод об- 
ратного вБгзова. Зто предотврагцает параллелвное вБгполнение метода таимера 
в несколБКих потоках. 

□ Класс DispatcherTimer из пространства имен System.Windows.Threading. 

Зтот класс нвлиетсл зквивалентом класса Т imer из пространства имен System . 
Windows . Forms длл приложении Silverlight и WPF. 

□ Класс DispatcherTimer из пространства имен Windows.UI.XAML. Зтот класс 
ивлнетсл зквивалентом класса Timer из пространства имен System.Windows . 
Forms длн приложении Windows Store. 

□ Класс Timer из пространства имен System.Timers. Зтот класс пвлиетсл, по 
сути, оболочкои длн класса Timer из пространства имен System . Threading. Он 
заставлиет CLR по срабатБгваниго таимера ставитБ со6бгтин в очередв пула по- 
токов. ПосколБку класс System . Т imers . Т imer нвлнетсл производнБгм от класса 
Component из пространства имен System . ComponentModel, таимервг можно раз- 
мевдатв в рабочеи области конструктора форм приложенгш Visual Studio. Кроме 
того, он предоставлпет своиства и собвгтил, упровдаговдие его исполБЗОвание 
в конструкторах Visual Studio. Зтот класс понвилсн в FCL в те времена, когда 
у Microsoft евде отсутствовала четкал концепцгш потоков и таимеров. Вообвде 
говорн, его стоило 6 бг удалитБ, оставив его функции классу System . Threading . 
Т imer. Л никогда не работаго с классом System . Т imers . Т imer и не советуго зтого 
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вам (разве что вам совершенно необходимо разместитБ таимер в рабочеи области 
конструктора форм). 


Как пул управллет потоками 

В зтом разделе м хотел 6bi остановитћсч на том, каким образом пул управллет ра- 
бочими потоками и потоками ввода-ввшода. Глубоко погружатБСи в детали mbi не 
будем, так как внутреннчч реализацин зтого процесса меннласв при переходе от 
однои версии CLR к другои и навернчка изменитси в будугцем. Позтому пул по- 
токов можно представитв в виде черного чгцика. Врнд ли он окажетсл идеалвнвш 
решением длл какого-то конкретного приложенгш, так как зта технологгш пла- 
нировангш потоков обгцего назначенгш рассчитана на работу в широком спектре 
приложении. Длл некоторвгх приложении она подходит лучше, чем длл других. 
Впрочем, на сегоднншнгш денв она прекрасно справлиетсл со своими задачами, 
и л рекомендуго отнестисв к неи с доверием. Врнд ли bbi сможете самостонтелвно 
написатБ пул потоков, которвпг будет функционироватБ лучше, чем поставлчемБпг 
в составе CLR. Так как с течением времени внутренннн система управленгш пото- 
ками у пула мениетсл, многие приложенгш начинагот работатв лучше. 

Ограничение количества потоков в пуле 

CLR позволнет указатв максималБно возможное количество потоков, создавае- 
MBix пулом. Однако вознггкает огцугценгге, что задаватв верхнгги предел длл пула 
не стоит, потому что зто может прггвести к зависанггго ггли взаимнои блокггровке. 
Представвте очередБ из 1000 рабочих злементов, заблокггрованнуго сигналвнБгм 
собБгтием злемента под номером 1001. Если верхнгш предел дли количества пото- 
ков равен 1000, зтот новбш поток исполнен не будет, а значит, всн твгслча потоков 
навсегда окажетсл заблокггрованнои. Конечному полвзователго останетсл толбко 
завершитБ работу приложенгш, потерчв несохраненнвге даннвге. Разработчикгг 
обкшно не накладншагот ггскусственнБгх ограничении на доступнБге длн прггложенгш 
ресурсБт Кому захочетсн при запуске прггложенгш ограничиватБ обвем ггсполБзуемои 
им памнти или пропускнуго способностн канала свнзи? И все же по каким-то при- 
чггнам некоторвге разработчикгг считагот возможнбш ограничиватБ максималБное 
количество потоков в пуле. 

Из-за проблем, свчзаннвгх с зависангшми и взагшнБши блокгтровкамгг, разработ- 
чттктт CLR постоннно увеличггвагот заданное по умолчанттто максгшалвно возможное 
количество потоков в пуле. В настонгцее времн предел составлнет 1000 потоков, что 
длч 32-разридного процесса, имегогцего не менее 2 Гбаит адресного пространства, 
может рассматриватБСн как отсутствие огранггченгш. После загрузки библиотек 
Win32 и библиотек CLR, а также ввтделенгш собственнои и управллемои кучи 
остаетсн прггмерно 1,5 Гбаггт адресного пространства. Так как каждвпг поток требует 
длл стека в полвзователБСКом режиме и блока окруженгш (ТЕВ) более 1 Мбаит 
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памнти, в 32-разрндном процессе допустимо примерно 1360 потоков. Попмтки соз- 
датБ болБшее количество потоков приведут к исклгоченшо OutOfMemoryException. 
64-разрнднБ1и процесс предлагает 8 Тбаит адресного пространства, так что теорети- 
чески Bbi можете создаватБ сотни тб 1 Сич потоков. Но зто будет пустал трата ресур- 
сов, особенно с учетом того факта, что идеалБное количество потоков совпадает с 
количеством процессоров. По идее разработчикам CLR следует убратБ ограниченин, 
но в настошции момент зто невозможно, так как в резулвтате прекратлт cboio ра- 
боту приложенин, разработаннвш в предположении об ограниченном количестве 
потоков в пуле. 

Класс System.Threading.ThreadPool предлагает несколБКО статическихмето- 
дов длл управленгга количеством потоков в пуле: GetMaxThreads, SetMaxThreads, 
GetMinThreads, SetMinThreads iiGetAvailableThreads. Впрочем, ннерекомендуго 
ими полвзоватБСн. Попб 1 тки меннтБ заданнБ1е по умолчаниго ограниченгга о6бшно 
ухудшагот работу приложении. Если вб 1 считаете, что вашему приложениго требу- 
готсл сотни или даже тбголчи потоков, скорее всего, что-то не так с архитектурои 
приложенгга или механизмом исполвзовашш потоков. О том, как правилвно при- 
меннтБ потоки, мб 1 поговорим в зтои главе и в главе 28. 

Управление рабочими потоками 

На рис. 27.1 показанБ 1 ра.злич i ii>i с структурБ 1 даннБ 1 Х, делагогцие рабочие потоки 
частБГО пула. Метод ThreadPool .QueueUserWorkItem и класс Timer всегдапомеша- 
гот рабочие злеметтл в глобалБнуго очередв. Рабочие потоки берут злементБ 1 длл 
обработки из очереди по алгоритму «первБ 1 м пришел — первБш ушел». А так как 
при наличии несколБКих потоков злементБ1 из глобалБнои очереди могут удалнтБСн 
одновременно, все рабочие потоки конкуриругот за право на блокировку в рамках 
синхронизации потоков, которое гарантирует, что никакие два или более потока 
не смогут одновременно обрабатБшатв один и тот же злемент. В некоторБ1х прило- 
жешгах зто право на блокировку становитсл узким местом, до некоторои степени 
ограничивагогцим масштабируемоств и производителБностБ. 

Рассмотрим процесс планировашга задании с помогцбго заданного по умолчаниго 
планировгцика (его можно получитБ через статическое своиство Def ault класса 
TaskScheduler) 1 . При планировангш задангга длл нерабочего потока обвект Task 
добавлнетсл в глобалБнуго очередв. При зто.м каждБнг рабочии поток обладает 
собственнои локалвнои очередБго, в которуго и добавлнготсн планируемБге задангга. 

Рабочии поток, готовбш к обработке злементов, сначала проверлет наличие 
обвектов Task в локалвнои очереди. Обнаружив такои обвект, он извгмает его из 
очереди и обрабатБгаает. ИзБитие производитсл по алгоритму <<последним при- 
шел — перввш ушел». Так как доступ к началу локалБнои очереди имеет толбко 
рабочии поток, блокировка в рамках синхронизации потоков болвше не требуетси, 


1 Поведение других обЂектов, производннх от класса TaskScheduler, может отличатЂсн от 
описнваемого в данном разделе. 
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а добавление задании в очередБ и изђлтис их из нее происходит оченв бћ 1 Стро. По- 
бочнБш зффектом такого поведенин ивлиетси то, что вБшолнение задании идет 
в поридке, обратном порндку их постановки в очередБ. 



/”^Т|ерабочиИ^\ 
V. поток^/ 


Рис. 27.1 . Пул потоков в CLR 


ВНИМАНИЕ 

Пул потоков не гарантирует определенного порпдка обработки злементов из 
очереди, особенно с учетом того факта, что наличие несколБких потоков делает 
возможнои одновременнук) обработку несколБких злементов. Проследите за тем, 
что 6 б 1 длл вашего приложенил порлдок обслуживанил злементов очереди не бмл 
принципиален. 


Обнаружив пустуго локалвнуго очередн, рабочии поток пБгтаетсл взитб задание 
из локалБнои очереди другого рабочего потока. Заданин, опнтб же, берутсл с конца 
очереди, а значит, требуетсл блокировка в рамках синхронизации потоков, что не- 
сколбко снижает производителБностБ. Остаетсл надеитБСи на то, что блокировка 
будет случатвси относителБно редко. Если пустнгми оказБшаготси все локалвнБге 
очереди, рабочии поток извлекает (прибеган к блокировке) злемент из глобалвнои 
очереди по алгоритму «первБш пришел — первнш ушел». В случае пустои глобалн- 
noii очереди рабочии поток переходит в режим ожиданин. Если зтот режим длитсл 
долго, поток просвшаетсн и самоуничтожаетсн, освобождан заннтвге рссурс bi (ндро, 
стеки, ТЕВ). 

Пул бкгстро создает рабочие потоки, а их количество определиетсл значением, 
переданнвш в метод SetMinThreads класса ThreadPool. Если bbi не ввгоБшали зтот 
метод (а вБ13БшатБ его не рекомендуетси), количество потоков по умолчаниго со- 
впадает с количеством процессоров, которме может задеиствоватв процесс. Оно 
определиетси маскои сходства (affinity mask) процесса. Обвшно процессу разре- 
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шаетсл исполћзоватБ все процессорм, и пул создает рабочие потоки, количество 
котормх бмстро достигает числа процессоров. Затем пул начинает отслеживатБ 
частоту завершентш рабочих злементов, и длл тех из них, вмполнение котормх 
занимает много времени (с недокументированнмм значением), создает дополни- 
телБнме потоки. При увеличении темпа завершешш злементов рабочие потоки 
уничтожаготсл. 



Глава 28. Асинхронн 1 > 1 е операции 
ввода-вшвода 


В предмдушеи главе рассматривалисБ возможности асинхронного вмполненин 
вмчислителБнмх операции, когда пул потоков распределнет заданин среди много- 
численнмх ндер, обеспечиван параллелБное исполнение потоков, что позволиет по- 
вмситб производителБностБ за счет более зффективного расходованин ресурсов си- 
стемБт В зтои главе речв идет об асинхронном ВБШолнении операции ввода-вБшода, 
когда аппаратное обеспечение решает свои задачи вообгце без участии потоков 
и процессора. Зто, несомненно, оказвшает влипние на зффективноств расходовангш 
системнвгх ресурсов, так как в зтом случае зти ресурсвг вообгце не потреблнготсл. 
Впрочем, пул потоков исполненин все равно играет важнуго ролв, так как именно 
там обрабатБшаготси резулБтатБ! разнообразнБгх операции ввода-вБшода. 


Операции ввода-вмвода в Windows 

Длн начала рассмотрим, как в Microsoft Windows вбшолнпготсн синхроннБге опе- 
рации ввода-вБшода. На рис. 28.1 показан компкготер с подсоединеннБш к нему 
перифериинБгм оборудованием. Каждое из устроиств снабжено собственнои 
платои со специализированнБш микропроцессором. К примеру, плата жесткого 
диска умеет врагцатк диск, устанавливатБ головку на нужнуго дорожку, читатв 
даннБге с диска и запискшатБ их на него, перемегцатБ даннБге в памитв компБГОтера 
иобратно. 

Что6б1 открбгтб дисковБги фаил в программе, разработчик создает обвект 
FileStneam. Далее методом Read читаготси даннвге из фаила. Вбгзов метода Read 
обвекта FileStneam сопровождаетсн переходом потока от управлнемого кода в ма- 
шиннбш код/код полБЗОвателБСКого режима, при зтом вкгзБшаетсп VV'i n '12 - (]>у и к n 11 и 
ReadFile ( 1 ). ОнавБгделнет памнтБ длн неболБшои структурБц назБшаемои пакетом 
запросов ввода-вБшода (I/O Request Packet, IRP) ( 2 ). Зта структура инициализи- 
руетсн дескриптором фаила, смегцением внутри фаила, с которого начнетсн чтение 
баитов, адресом массива Byte [ ], ввгделенного длл считБшаемБгх баитов, количеством 
баитов, предназначеннБгх длл передачи и т. п. 

Функцгш ReadFile обрагцаетси к идру Windows, переводл поток из кода полб- 
зователБСКого режима в код в режиме идра и передавап в идро IRP -структуру (3). 
По дескриптору устроиства ндро узнает, какое устроиство предназначено длл 
конкретнои операции ввода-ввшода, после чего пакет запросов ставитсн в IRP- 
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очередБ нужного драивера устроиства (4). КаждБш драивер устроиства управлнет 
собственнои очередвкз запросов ввода-ввшода от всех запугценнБ1х на машине про- 
цессов. При понвлении IRP -пакетов драивер устроиства передает содержагцукзсн в 
них информациго соответствугогцему устроиству, которое, собственно, и ввшолннет 
операциго ввода-вБшода (5). 


Синхроннни ввод-внвод в Windows 


.NET 


ПолвзователБ- 
скии режим 
в Win32 


FileStream fs = new FileStreamC...); 
lnt32 bytesRead = fs.Read(...); 



Рис. 28.1. Синхроннне операции ввода-внвода в Windows 


Необходимо помнитб одну важнуго подробноств: в процессе вБ 1 полненин 
устроиством операции ввода-ввшода поток исполненгш, передавшии запрос, про- 
стаивает, позтому Windows переводит его в спнгцее состонние, чтобвг не расходоватв 
процессорное времи впустуго (6). Однако при зтом поток продолжает заниматв 
место в памнти своим стеком полБЗОвателвского режима, стеком режима лдра, 
блоком переменнБгх окруженгш потока (Thread Environment Block, ТЕВ) и дру- 
гими структурами даннмх, которме в зтот момент не исполБзуготси. Приложенгш 
с графическим интерфеисом перестагот реагироватБ на деиствгш полвзователн на 
времи блокировки потока. Все зто, конечно, нежелателвно. 

После завершенгш устроиством операции ввода-ввгвода Windows пробуждает 
поток, ставит его в очередв процессора и позволиет ему вернутвсн из режима идра 
сначала в полБЗОвателБСКии режим, а затем и в управлиемБш код (7, 8 и 9). Метод 
Read обпекта FileStneam при зтом возврагцает значение типа Int32, содержагцее 
количество прочитаннвгх из фаила баитов. Зто дает вам информациго о количестве 
баитов, оказавшихсн в массиве Byte[ ], ранее переданном методу Read. 
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Представим реализацшо веб-приложенин, в которои длл каждого пришедшего 
на ваш сервер клиентского запроса формируетсл запрос к базе даннмх. При посту- 
плении клиентского запроса поток из пула потоков обрагцаетсл к вашему коду. При 
вмдаче синхронного запроса к базе даннмх зтот поток окажетсл заблокированнмм на 
неопределенное времч, необходимое длл полученил ответа из базм. Если в зто времл 
придет егце один клиентскии запрос, пул создаст егце один поток, которми снова ока- 
жетсл заблокированнмм. В итоге можно оказатБСл с целмм набором блокированнмх 
потоков, ожидагогцих ответа из базм даннмх. Получаетсл, что веб-сервер вмделлет 
массу ресурсов (потоков и памнти длл них), которме почти не исполБзуготсн! 

Проблема усугубллетсл тем, что при получении резулвтатов запросов из базБ 1 дан- 
нбгх блокировка с потоков будет сннта одновременно и все они начнут исполннтбсн. 
В ситуации, когда количество потоков значителвно превосходит количество ндер 
процессора, операционнан система прибегнет к частмм переклгоченинм контекста, 
что значителБно снизит производителБностБ. Так что зто не тот путк, которБШ по- 
зволил 6bi реализоватБ масштабируемое приложение. 

ТеперБ рассмотрим процедуру вБшолненич асинхроннБгх операции ввода-вБшода 
в Windows (рис. 28.2). И убрал со схемвг все внешние устроиства, кроме жесткого 
диска, а также добавил пул потоков средвг CLR и слегка отредактировал код. Открвг- 
тие фаила по-прежнему ввшолннетсл путем созданин обвекта FileStneam, но теперк 
ему передаетсн флаг FileOptions . Asynchnonous, которнш указБшает Windows, что 
операции чтенин из фаила и записи в фаил следует вбшолннтб асинхронно. 

Чтение данннгх из фаила теперБ вБшолннетсл методом BeginRead, а не методом 
Read. ReadAsync создает обвект Task<Int32>, представлнгонцш незавершеннуго 
операциго чтенич, а затем ввгзБшает Win32-^yHKunro Read File (1), которан вБгделлет 
место под IRP -пакет, инициализирует его, как и в предвгдугцем сценаргш (2), и пере- 
дает в идро Windows (3). Windows добавллет IRP -пакет в IRP -очередв драивера 
жесткого диска (4), но на зтот раз поток не блокируетсн, а немедленно возврагцает 
управление после вбгзовов метода BeginRead (5,6 и 7). Конечно, зто может произои- 
ти егце до обработки IRP -пакета, позтому после ReadAsync не может следоватв код, 
которБш пБгтаетсн обратитБСн к баитам в переданном методу массиве Byte [ ]. 

Может возникнутБ вопрос, когда и каким образом обрабатвшаготсн считБшаемБге 
даннБге? ПривБгзове ReadAsync возврагцаетснобвект Task<Int32>. Исполвзунзтот 
обвект, можно вкгзватБ метод ContinueUlith длл регистрацгш метода обратного вбгзо- 
ва, которвпг должен вбшолннтбсн при завершении задачи, а затем обработатв даннБге 
в методе обратного ввгзова. Также можно исполвзоватБ асинхроннБге функции С#, 
позволлгогцие исполБЗОватБ последователБнуго структуру кода (как пргг вБгполненгггг 
сггнхронного ввода-вБгвода). 

Закончив обработку IRP -пакета (п), устроиство помегцает делегат в очередв 
CLR -пула потоков (h). В далвнеишем какои-то из потоков пула берет готовбги IRP- 
пакет и активизирует метод обратного ввгзова (с) 1 . В резулвтате вбг узнаете о за- 


1 ГотовБге IRP -пакетБг извлекаготсл из пула по алгоритму «перввгм пришел — первБгм 
обслужен>>. 
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вершении операции, а обрашении к данншм массива Byte [ ] внутри метода станут 
безопаснмми. 
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Рис. 28.2. Асинхроннв 1 е операции ввода-вшвода в Windows 


Tenepb, разобравшисд с основами, посмотрим на откршвакнциеси перед нами 
перспективш. Предположим, в ответ на клиентскии запрос сервер вшдает асин- 
хроннми запрос к базе даннмх. При зтом наш поток не блокируетсн, а возврашдетси 
в пул, получаи возможностб заннтБСи обработкои других клиентских запросов. 
Таким образом, получаетсн, что дли обработки всех входигцих запросов достаточно 
всего одного потока. Полученнми от базм даннмх ответ также окажетсл в очереди 
пула потоков, то естд наш поток сможет тут же его обработатБ и отправитБ даншле 
клиенту. Таким образом, единственнБш поток обрабатБшает не толбко клиентские 
запросБц но и все ответБ 1 базБ 1 даннБ 1 х. В итоге сервер практически не потребллет 
системнБ1х ресурсов, но работает с максималБно возможнои скоростБкз, так как 
переклгоченин контекста не происходит! 

Если злементБ 1 понвлнготси в пуле бБШтрее, чем поток может их обработатБ, 
пул может создатБ дополнителБНБге потоки. Пул 6bicrpo создаст по одному по- 
току на каждБш процессор. Соответственно, на машине с четБфБмн процессорами 
четБфе клиентских запроса к базе даннБ1х и ответа базБ! даннБ1х (в лгобои комби- 
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нации) будут обрабатмватБСн в четБ1рех потоках без какого-либо переклкзченин 
контекста 1 . 

Однако при блокировке потока (ввшолнении синхроннои операции ввода-вБ1- 
вода, вБ 130 ве метода Thread . Sleep или ожидании, свизанном с блокировкои потока 
в рамках синхронизации потоков) Windows уведомллет пул о том, что один из его 
потоков прекратил работу. Пул длн восполненгш недостаточнои загрузки процес- 
сора создает новбш поток взамен заблокированного. К сожаленшо, такои вбгход 
из положенгш не идеален, потому что создание нового потока обходитсл доволбно 
дорого с точки зренгш затрат времени и памлти. 

Кроме того, позднее поток может 6бгтб разблокирован, и в итоге процессор 
окажетсл перегруженнвгм, что приведет к переклгочениго контекста и снижениго 
производителБности. Впрочем, зта проблема решаетсл средствами пула. Завер- 
шившим свого работу потокам, которвге вернулисв в пул, не дагот обрабатвгватв 
новБге злементБг, пока загрузка процессора не достигнет определенного уровнн. 
Таким способом уменвшаетсл количество переклгочении контекста и поввгшаетси 
производителБностБ. Если впоследствии пул обнаружит, что потоков болвше, чем 
необходимо, он просто позволит лишним потокам самоуничтожитБСи, освободив 
ресурсвг. 

Длл реализации описанного поведенгш CLR -пул потоков исполБзует такои 
ресурс Windows, как порт завершенил ввода-вивода (I/O Completion Port). Он 
создаетсл при инициализации CLR. Затем с зтим портом можно свизатБ подсо- 
единнемБге устроиства, чтобвг в резулвтате их драиверБг «знали», куда поставитн в 
очередв IRP -пакет. Подробнее зтот механизм описан в моеи книге «Windows via 
С/С++» (Microsoft Press, 2007). 

АсинхроннБги ввод-вбгвод кроме минималБного исполБЗОвангш ресурсов гг уменв- 
шенггн количества переклгочении контекста предоставлнет и другие преимугцества. 
Скажем, в начале сборки мусора CLR приостанавливает все потоки в процессе. 
Получаетсл, чем менвше у нас потоков, тем бвгстрее проггзоидет уборка мусора. 
Кроме того, при уборке мусора CLR просматривает в поггсках корнегг все стекгг по- 
токов. Соответственно, чем менвше у нас потоков, тем менвше стеков приходитси 
просматриватв и тем бБгстрее работает уборгцггк мусора. Плгос ко всему, если в про- 
цессе обработкгг потокгг не бвглгг заблокированвг, болБшуго частБ временгг онгт будут 


1 Предполагаетса, что другие потоки в зто времн отсутствугот. БолБшуго частв времени 
деиствителБно так, ведв болБшинство компвготеров не задеиствует процессор на 100 %. 
Однако даже при полнои загрузке процессора все будет работатв описаннБгм образом, если 
исполнлемБге потоки имегот низкие приоритетБГ. Наличие других потоков приводит к пере- 
клгоченгшм контекста. Зто плохо с точки зренин производителвности, но хорошо с точки 
зренил надежности. Напоминаго, что Windows ВБГделлет на каждБпг процесс по краинеи 
мере один поток и переклгочает контекст, гарантирул, что даже блокировка одного потока 
не остановит работу приложеншг. 
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проводитБ в пуле в режиме ожиданин. А значит, в начале уборки мусора потоки 
окажутси наверху стека, и поиск корнеи не заимет много времени. 

При достижении отлаживаемћш приложением точки останова Windows при- 
останавливает все его потоки. После возврагценгш к отладке следует возобновитв 
все потоки, а значит, при наличии болвшого количества потоков пошагован отладка 
будет вбшолннтбсн краине медленно. АсинхроннБпг ввод-вбшод позволнет обоитисв 
всего несколБКими потоками, поншпаи тем самкш производителБностБ отладки. 

Вб 1 годб 1 зтим не исчерпБшаготсн. Предположим, ваше приложение должно за- 
грузитв с различнБгх саитов 10 изображении. Загрузка каждого из них занимает 
5 секунд. В синхронном режиме вБшолненгш (загрузка одного изображенгш за 
другам) вам потребуетсл 50 секунд. Однако при помогци всего одного потока можно 
начатв 10 асинхроннБгх операции загрузки и получитк все изображенгш всего за 
5 секунд! То еств времн вБшолненин несколБких синхроннБгх операции ввода-вБшода 
получаетсн путем суммированин времени, которое занимает каждан отделвнан опе- 
рацин, в то времл как в случае набора асинхроннвгх операции ввода-вБшода времн 
их завершенгш определлетсл самои медленнои из ввшолннемБгх операции. 

Длн приложении с графическим интерфеисом асинхроннБге операции открнша- 
гот егце одно преимугцество: их интерфеис всегда реагирует на деиствгш конечного 
полБЗОвателн. В приложенгшх Silverlight и Windows Store вообгце все операции 
ввода-вБшода вбшолннготси толбко асинхронно, потому что библиотеки классов 
операции ввода-ввшода предоставлнгот толбко асинхроннБге версии своих операцгш; 
методвг вБшолненгш синхроннБгх операции просто отсутствугот. Зто 6бшо сделано 
намеренно, что6бг приложение не переставало реагироватв на деиствгш конечного 
полвзователл. 


Асинхроннне функции C# 

Асгшхроннвге операции нвлнготси клгочом к созданиго ввгсокопроизводителБНБгх 
масштабируемБгх приложении, вбшолннгогцих множество операции при помогци 
неболвшого количества потоков. Вместе с пулом потоков они дагот возможностб 
зффективно задеиствоватБ все процессорвг в системе. Осознаван зтот огромнвш 
потенциал, разработчики CLR разработали моделк программировангш, призваннуго 
сделатв его доступнБгм дли всех программистов 1 . Зта моделв исполБзует обвектБг 


1 Разработчики, исполБзукнцие версии Microsoft .NET Framework до 4.5, могут восполб- 
зоватБСн моим классом AsyncEnumerator (из библиотеки Power Threading — см. http:// 
Wintellect.com/) — его моделп программированил достаточно похожа на моделв .NET 
Framework 4.5. Собственно, успех класса AsnycEnumerator позволил мне помочб Microsoft 
в проектировании модели, рассматриваемои в зтои главе. Ввиду их сходства адаптацил 
кода, исполБзугогцего класс AsyncEnumerator, длл новои программнои модели проходит 
тривиалБно. 
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Task (см. главу 27) и асинхронние функции измка С#. В следугошем примере кода 
асинхроннме функции исполБзуготсл длл вмполненин двух асинхроннмх операции. 

private static async Task<String> IssueClientRequestAsync(String serverName, 

String message) 

{ 

using (var pipe = new NamedPipeClientStream(serverNamej "PipeName"j 
PipeDirection.InOut, PipeOptions.Asynchronous | PipeOptions.WriteThrough)) 

{ 

pipe.Connect(); // Прежде чем задавати ReadMode, необходимо 
pipe.ReadMode = PipeTransmissionMode.Message; // внзватв Connect 

// Асинхроннав отправка даннмх серверу 
Byte[] request = Encoding.UTF8.GetBytes(message); 
await pipe.WriteAsync(request, <д, request.Length); 

// Асинхронное чтение ответа сервера 
Byte[] response = new Byte[1000]; 

Int32 bytesRead = await pipe.ReadAsync(response, 0, response.Length); 
return Encoding.UTF8.GetString(responsej <д, bytesRead); 

} // Закрнтие канала 

} 


B приведенномкодесразу видно,что IssueClientRequestAsync нвлнетсл асин- 
хроннои функциеи, потому что клгочевое слово async следует в первои строке сразу 
же после static. Когда метод помечаетсл клгочевмм словом async, компиллтор 
преобразует код метода в тип, реализугогции конечнми автомат (более подробное 
описание приводитсл в следугогцем разделе). Зто позволлет потоку вмполнитб 
частБ кода в конечном автомате, а затем вернутБ управление без ввшолнешш все- 
го метода до завершенгш. Таким образом, при ввтзове IssueClientRequestAsync 
поток конструирует NamedPipeClientStream, вБ13Б1вает Connect, задает значе- 
ние своиства ReadMode, преобразует переданное сообгцение в Byte[ ] и вБИБшает 
WriteAsync. Внутренннн реализацил WriteAsync создает обвект Task и воз- 
врашает его IssueClientRequestAsync. На зтои стадии оператор C# await bbi- 
ЗБ 1 вает ContinueWith длл обвекта Task с передачеи метода, возобновлнгогцего 
вБшолнение конечного автомата, после чего поток возврагцает управление из 
IssueClientRequestAsync. 

В будугцем драивер сетевого устроиства завершит записв даннБ 1 х в канал. По- 
ток из пула оповестит обвект Та s k, что приведет к активизации метода обратного 
вБ130ва ContinueWith, заставлнгогцего поток возобновитв вБшолнение конечного 
автомата. А если конкретнее, поток заново входит в метод IssueClientRequestAsync, 
но в точке оператора await. Теперв наш метод вбшолнит сгенерированнБпг компи- 
литором код, запрашивагогции состоиние обвекта Task. В случае ошибки ввгдаетси 
представлигогцее ее исклгочение. Если операцгш завершаетсл успешно, оператор 
await возврагцает резулвтат. В нашем случае WriteAsync возврагцает Task вместо 
Task<TResult>, так что возврагцаемое значение отсутствует. 
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Далее вмполнение нашего метода продолжаетсн созданием обвекта Byte [ ] и по- 
следуклцим вмзовом асинхронного метода ReadAsync длн NamedPipeClientStneam. 
Внутренннн реализаци ReadAsync создает обвект Task<Int32> и возврашает его. 
И снова оператор await вмзмвает ContinueWith длн обвекта Task<Int32> с пере- 
дачеи метода, возобновлнгогцего вмполнение конечного автомата, и снова поток 
возврашает управление из IssueClientRequestAsync. 

В будугцем сервер вернет ответ клиентскои машине, драивер сетевого устрои- 
ства получит зтот ответ, а поток из пула уведомит обвект Task<Int32>, кото- 
рми возобновит вмполнение конечного автомата. Оператор await заставллет 
компилнтор сгенерироватБ код, которми запрашивает своиство Result обвекта 
Task (Int32) и присваивает резулБтат локалБнои переменнои bytesRead, или 
вћвдает исклгочение в случае ошибки. Затем ввшолннетсл оставшаисн частв кода 
IssueClientRequestAsync, которан возврашает строку резулвтата и закрБшает канал. 
На зтои стадии конечнкш автомат отработал до завершенгш, а уборгцик мусора при 
необходимости освободит памнтв. 

Так как асинхроннБге функции возврагцагот управление до того, как их конеч- 
нбш автомат отработает до завершенгш, ввшолнение метода, вБ13вавшего Issue- 
ClientRequestAsync, продолжитсн сразу же после того, как IssueClientRequestAsync 
вбшолнит свои первБпз оператор await. Но как вБ13Б1вагогцаи сторона узнает, что 
вБшолнение конечного автомата IssueClientRequestAsync завершилосв? КогдавБ 1 
помечаете метод клгочевнш словом async, компилнтор автоматически генерирует 
код, создагогции обвект Task в начале ввшолнешш конечного автомата; зтот обвект 
Task завершаетсн автоматически при завершении конечного автомата. Заметвте, что 
типомвозврагцаемогозначенин IssueClientRequestAsync нвлнетсл Task<String>. 
Фактически возврагцаетсл обвект Task<String>, которвги создаетсл кодом, сгене- 
рированнвш компи лнтором, а своиство Re s u lt обвекта Ta s k в данном случае имеет 
тип String. Ближе к концу IssueClientRequestAsync н возврашаго строку. Зто 
заставлнет код, сгенерированнвш компилитором, завершитв созданнБпг им обвект 
Task<String> и задатн его своиству Result возврагценнуго строку. 

Длн асинхроннвгх функции деиствует рнд ограничении: 

□ Метод Main приложенгш не может 6бгтб преобразован в асинхроннуго функциго. 
Кроме того, конструкторвг, методБг доступа своиств и методвг доступа со6бгтни 
не могут 6бгтб преобразованБг в асинхроннвге функцгш. 

□ Асинхроннан функцгш не может иметн параметрБг out и ref . 

□ Оператор await не может исполБЗОватБСн в блоке catch, f inally или unsafe. 

□ Не допускаетсл установление блокировки, поддерживагогцеи владение пото- 
ком или рекурсиго, до операцгш await, и ее сннтие после оператора await. Зто 
ограничение обБнсниетсн тем, что один поток может вбшолнитб код до await, 
а другои поток может вбшолнитб код после await. При исполБЗОвангш await 
с командои C# lock компиллтор ввгдает сообгцение об ошибке. Если вместо 
зтого нвно ввгзватБ методБг Enter и Exit класса Monitor, то код откомпилиру- 
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етсл, но Monitor . Exit вмдаст исклкзчение SynchronizationLockException во 
времн вмполненин. 

□ В вмраженинх запросов оператор awa it может исполБЗОватБСн толбко в первом 
вБ1ражении коллекции условил f rom или в вБфажении коллекции условил 

join. 

Все зти ограниченин не столб сугцественнБк При их нарушении компилнтор вбн 
даст соответствугогцее сообгцение, а проблемБ 1 о6бшно удаетсн решитн при помогци 
незначителБнои модификации кода. 


Преобразование асинхроннои функции 
в конечнБш автомат 

Работа с асинхроннБши функцинми станет более зффективнои, если bbi будете по- 
ниматв сутБ преобразовании кода, которвш компилитор ввшолннет за вас. На мои 
взглид, разобратвсн в происходнгцем прогце всего на конкретном примере, позтому 
мб 1 начнем с определенгш несколнких просткгх типов и методов. 

internal sealed class Typel { } 
internal sealed class Type2 { } 
private static async Task<Typel> MethodlAsync() { 

/* Асинхроннап операцин, возврацаккцап обцект Typel */ 

} 

private static async Task<Type2> Method2Async() { 

/* Асинхроннан операцин, возврацаккцав обцект Туре2 */ 

} 


Теперв н приведу асинхроннуго функциго, которан исполвзует зти простБге типбг 
и методБ1. 

private static async Task<String> MyMethodAsync(Int32 argument) { 

Int32 local = argument; 
try { 

Typel resultl = await MethodlAsync(); 
for (Int32 х = 0; х < 3; x++) { 

Type2 result2 = await Method2Async(); 

} 

} 

catch (Exception) { 

Console.WriteLine("Catch"); 

} 

finally { 

Console.WriteLine("Finally"); 

} 

return "Done"; 
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Код MyMethodAsync вмглддит доволбно запутанно, но он демонстрирует не- 
сколбко клк)чевБ 1 х моментов. Во-первБ 1 х, сама асинхроннал функцин возврашает 
Task<String>, но в теле кода возврашаетсл String. Во-вторвж, в неи вБ13Б1вак)тсл 
другие функции, которвге вбшолнлгот асинхроннБ1е операции — одна автономно, 
другал в цикле for. Наконец, также присутствует код обработки исклгочении. 
При компилиции MyMethodAsync компиллтор преобразует код метода в структуру 
конечного автомата с возможностбго приостановки и продолжениц вБшолненил. 

И взил приведеннБш код, откомпилировал его, а затем преобразовал IL -код 
обратно в ИСХОДНБ 1 И код С#. Далее л слегка упростил код и добавил подробнвге 
комментарии, что6б1 вб1 поннли, что делает компилнтор дли работБ1 асинхроннБж 
функции. Ниже приведен основнои код, созданнБ 1 и в резулвтате преобразованин. 
Л показБшаго как преобразованнБш метод MyMethodAsync, так и структуру конечного 
автомата, от которои он зависит. 

// Атрибут AsyncStateMachine обозначает асинхроннми метод 
// (полезно длл инструментов, исполБзук)цих отражение); 

// тип указмваетЈ какал структура реализует конечнми автомат. 

[DebuggenStepThrough, AsyncStateMachine(typeof(StateMachine) )] 
private static Task<String> MyMethodAsync(Int32 argument) { 

// Создание зкземпллра конечного автомата и его инициализацил 
StateMachine stateMachine = new StateMachine( ) { 

// Создание построителл, возврашаклцего Task<String> . 

// Конечнми автомат обрацаетсл к построителк) длл назначенил 
// завершенил заданил или вмдачи исклшченил. 
m_builder = AsyncTaskMethodBuilder<String>.Create() , 

m_state = 1, II инициализацил местонахожденил 

m_argument = argument // Копирование аргументов в полл конечного 
}; // автомата 

// Начало вмполненил конечного автомата. 
stateMachine.m_builder.Start(ref stateMachine); 

return stateMachine.m_builder.Task; // Возврацение заданил конечного 
} // автомата 

// Структура конечного автомата 

[CompilerGenerated , StructLayout(LayoutKind . Auto)] 
private struct StateMachine : IAsyncStateMachine { 

// Полл длл построителл конечного автомата (Task) и его местонахожденил 
public AsyncTaskMethodBuilder<String> m_builder; 
public Int32 m_state; 

// Аргумент и локалцнше переменнме становлтсл поллми: 
public Int32 m_argument, m_local, m_x; 
public Typel m_resultTypel; 
public Type2 m_resultType2; 

// Одно поле на каждми тип Awaiter. 

// В либои момент времени важно толбко одно из зтих полеи. В нем 
// хранитсл ссмлка на последнии вшполненнми зкземпллр await, 

// которши завершаетсл асинхронно: 
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private TaskAwaiter<Typel> m_awaiterTypel; 
private TaskAwaiter<Type2> m_awaiterType2; 

// Сам конечнни автомат 

void IAsyncStateMachine.MoveNext() { 

String result = null; // Резулвтат Task 

// Вставленнни компилвтором блок try гарантирует 
// завершение заданил конечного автомата 
try { 

Boolean executeFinally = true; // Логическии вшход из блока Чгу’ 
if (m_state == 1) { // Если метод конечного автомата 

// внполнветсл впервме 

m_local = m_argument; // Внполнитв начало исходного метода 

} 

// Блок try из исходного кода 
try { 

TaskAwaiter<Typel> awaiterTypel; 

TaskAwaiter<Type2> awaiterType2; 

switch (m_state) { 

case 1: // Начало исполненил кода в 'try' 

// внзвати MethodlAsync и получитв его обБект ожиданин 
awaiterTypel = MethodlAsync().GetAwaiter(); 
if (!awaiterTypel.IsCompleted) { 

m_state =0; // 'MethodlAsync' 

// завершаетсл асинхронно 

m_awaiterTypel = awaiterTypel; // Сохранити обБект 

// ожиданил до возвраценил 
// ПриказатБ обћекту ожиданил внзвати MoveNext 
// после завершенив операции 

m_builder.AwaitUnsafeOnCompleted(ref awaiterTypel, ref this); 

// Предшдуцав строка внзшвает метод OnCompleted 
// обвекта awaiterTypel, что приводит к вшзову 
// ContinueWith(t => MoveNext()) длл Task. 

// При завершении Task ContinueWith внзмвает MoveNext 

executeFinally = false; // Без логического вшхода 

// из блока 'try' 

return; // Поток возврацает 

} // управление внзшваккцеи стороне 

// ’MethodlAsync ' завершаетсл синхронно. 
break; 

case 0: // ’MethodlAsync ' завершаетсл асинхронно 

awaiterTypel = m_awaiterTypel; // Восстановление последнего 
break; // обвекта ожиданил 

case 1: // 'Method2Async ' завершаетсл асинхронно 

awaiterType2 = m_awaiterType2; // Восстановление последнего 
goto ForLoopEpilog; // обвекта ожиданил 

} 

// После первого await сохранлем резулцтат и запускаем цикл 'for' 

продолжение & 
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m_resultTypel = awaiterTypel.GetResult(); // Получение резулвтата 
ForLoopPrologue : 

m_x = 0; // Инициализацил цикла 'for' 

goto ForLoopBody; // Переход к телу цикла ’for' 

ForLoopEpilog: 

m_resultType2 = awaiterType2.GetResult(); 

m_x++; // Увеличение х после каждои итерации 

// Переход к телу цикла 'for' 

ForLoopBody : 

if (m_x < 3) { // Условие цикла ’for' 

// Bbi30B Method2Async и получение обцекта ожиданил 
awaiterType2 = Method2Async().GetAwaiter(); 
if (!awaiterType2.IsCompleted) { 

m_state = 1; // ’Method2Async' завершаетсл 

// асинхронно 

m_awaiterType2 = awaiterType2; // Сохранение обБекта 

// ожиданил до возврашенил 

// Приказмваем вшзватц MoveNext при завершении операции 
m_builder.AwaitUnsafeOnCompleted(ref awaiterType2j ref this) 
executeFinally = false; // Без логического вшхода 

// из блока 'try' 

return; // Поток возврацает управление 

} // BbBbiBaromen стороне 

// 'Method2Async ' завершаетсл синхронно 

goto ForLoopEpilog; // Синхронное завершение, возврат 

} 

} 

catch (Exception) { 

Console . WriteLine("Catch"); 

} 

finally { 

// Каждши раз, когда блок физически вшходит из 'try'j 
// вшполнлетсл ’finally'. 

// Зтот код должен вшполнлтбсл толбко при логическом 
// вшходе из 'try'. 
if (executeFinally) { 

Console.WriteLine("Finally"); 

} 

} 

result = "Done"; // To, что в конечном итоге должна вернутц 
} // асинхроннал функцил. 

catch (Exception exception) { 

// Необработанное исклгочение: задание конечного автомата 
// завершаетсл с исклгочением. 
m_builder.SetException(exception) ; 
return; 

} 

// Исклгоченил нет: задание конечного автомата завершаетсл с резулцтатом 
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m_builder.SetResult(result); 

} 

} 

Если вм не пожалеете времени на просмотр кода и чтение комментариев, думаго, 
вм сможете noHHTb, что компилнтор делает за вас. Пожалуи, стоит особо упомипутР) 
об одном важном моменте. Каждми раз, когда в вашем коде исполвзуетсн оператор 
await, компилнтор берет указаннми операнд и пмтаетсл вмзватв дли него метод 
GetAwaiter. Зтот метод может бмти как зкземплнрнмм методом, так и методом 
расширенгш. Обвект, возврагцаемми при вмзове GetAwaiter, назмваетсн обЂектом 
ожиданш (awaiter). 

После того как конечнми автомат получит обвект ожиданил, он запрашивает 
его своиство IsCompleted. Если операцгш завершаетсн синхронно, возврагцаетсн 
значение true, и в поридке оптимизации конечнми автомат просто продолжает вм- 
полнение. Он вмзмвает метод GetResult обвекта ожидангш, которми либо вввдает 
исклгочение в случае неудачного вмполненгш операции, либо возврагцает резулкгат, 
если операцгш прошла успешно. Конечнми автомат продолжает вмполнение дли 
обработки резулвгата. 

Если операцгш завершаетси асинхронно, IsCompleted возврагцает false. В зтом 
случае конечнми автомат вмзмвает метод OnCompleted обвекта ожиданил, переда- 
ван ему делегата метода MoveNext конечного автомата. И Tenepb конечнми автомат 
позволнет своему потоку вернутв управление в исходнуго точку, чтобм тот мог про- 
должитв вмполнение другого кода. В будугцем обвект ожидангш, инкапсулиругогции 
Task, узнает о своем заверении и вмзмвает делегата, что приводит к вмполненшо 
MoveNext. По полнм конечного автомата определлетсн способ перехода к правшљиои 
точке кода, что создает иллгозшо продолженгш вмполненгш метода с того места, 
с которого он бмл прерван. На зтои стадии код вмзмвает метод GetResult обвекта 
ожиданил и продолжает вмполнение длл обработки резулкгата. 

Так работает модели асинхроннмх функции, единственнан цели которои — упро- 
гцение работм программиста по написаншо кода без блокировки исполненгш. 


РасширлемостБ асинхроннмх функции 

Что касаетсл расширнемости, если в обвект Task можно упаковатв операцшо, 
которал завершитсл в будугцем, то вм сможете исполвзоватв оператор await длл 
ожиданил завершенгш зтои операции. Представление всех разновидностеи асин- 
хроннмх операции одним типом (Task) чрезвмчаино полезно, потому что оно 
позволлет реализоватв комбинаторм (методм WhenAll и WhenAny класса Task) и 
другие полезнме операцгш. Позднее в зтои главе даннан возможноств будет про- 
демонстрирована на примере упаковки CancellationToken с Task, позволнгогцем 
испо. 11 ); 10 ватР) await длн асинхроннои операции с поддержкои таим-аута и отменм. 

Асеичас н представлго егце один пример. Ниже приведен Moii класс TaskLogger, 
которми может nciio.iitsoisaTbCTi длн вмвода информацгш о незавершеннмх асин- 
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хроннмх операцинх. Такаи информацин чрезвмчаино полезна в ходе отладки, осо- 
бенно если ваше приложение <<виснет» из-за некорректного запроса или отсутствин 
реакции сервера. 

public static class TaskLogger { 

public enum TaskLogLevel { None, Pending } 
public static TaskLogLevel LogLevel { get; set; } 

public sealed class TaskLogEntry { 

public Task Task { get; internal set; } 
public String Tag { get; internal set; } 
public DateTime LogTime { get; internal set; } 
public String CallerMemberName { get; internal set; } 
public String CallerFilePath { get; internal set; } 
public Int32 CallerLineNumber { get; internal set; } 
public override string ToString() { 

return String.Format("LogTime={0}, Tag={l}, Member={2}, File={3}({4})"j 
LogTime, Tag ?? "(none)", CallerMemberName, CallerFilePathj 
CallerLineNumber); 

} 

} 

private static readonly ConcurrentDictionary<Taskj TaskLogEntry> s_log = 
new ConcurrentDictionary<Task, TaskLogEntry>(); 
public static IEnumerable<TaskLogEntry> GetLogEntries() { return s_log.Values; } 

public static Task<TResult> Log<TResult>(this Task<TResult> task, 

String tag = null, 

[CallerMemberName] String callerMemberName = null, 

[CallerFilePath] String callerFilePath = null, 

[CallerLineNumber] Int32 callerLineNumber = 1) { 
return (Task<TResult>) 

Log((Task)task, tag, callerMemberName, callerFilePath, callerLineNumber); 


public static Task Log(this Task task, String tag = null, 
[CallerMemberName] String callerMemberName = null, 
[CallerFilePath] String callerFilePath = null, 
[CallerLineNumber] Int32 callerLineNumber = 1) { 
if (LogLevel == TaskLogLevel.None) return task; 
var logEntry = new TaskLogEntry { 

Task = task, 

LogTime = DateTime.Now, 

Tag = tag, 

CallerMemberName = callerMemberName, 

CallerFilePath = callerFilePath, 

CallerLineNumber = callerLineNumber 

}; 

s_l°g[task] = logEntry; 

task.ContinueWith(t => { TaskLogEntry entry; 
s_log.TryRemove(t, out entry); }, 
TaskContinuationOptions.ExecuteSynchronously); 
return task; 

} 

} 
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Следукиции фрагмент кода демонстрирует исполБзование класса: 

public static async Task Go() { 

#if DEBUG 

// ИсполБЗОвание TaskLogger приводит к лишним затратам памнти 
// и сниженив производителБностиЈ вклкјчитб длл отладочнои версии 
TaskLogger . LogLevel = TaskLogger.TaskLogLevel . Pending; 
ttendif 

// Запускаем 3 задачи; длн тестированил TaskLogger их продолжителвностБ 

// задаетсн нвно. 

var tasks = new List<Task> { 

Task.Delay(2000).Log("2s op"), 

Task.Delay(5000).Log("5s op"), 

Task.Delay(60@0).Log("6s op") 

}J 


try { 

// Ожидание всех задач c отменои через 3 секундш; толвко одна задача 
// должна завершитвсл в указанное времл. 

// Примечание: 1/JithCancellation - мои метод расширенил, 

// описаннни позднее в зтои главе. 
await Task.WhenAll(tasks) . 

WithCancellation(new CancellationTokenSource(3000).Token); 

} 

catch (OperationCanceledException) { } 

// Запрос информации o незавершенншх задачах и их сортировка 
// по убмваниш продолжителиности ожиданил 

foreach (var ор in TaskLogger.GetLogEntries().OrderBy(tle => tle.LogTime)) 

Console.WriteLine(op); 

} 

Построив и запустив зту программу, н получаго следуклции резулБтат: 

LogTime=7/16/2012 6:44:31 АМ, Tag= 6 s ор, Member=Go, 

File=C:\CLR via C#\Code\Ch281I00ps.cs(332) 

LogTime=7/16/2012 6:44:31 AM, Tag=5s op, Member=Go, 

File=C:\CLR via C#\Code\Ch281I00ps.cs(331) 

Нарнду c гибкостБК), обусловленнои исполБЗОванием Task, асинхроннБге функ- 
ции предоставлнгот егце одну точку расширенин: компилитор вБ13Б1вает GetAwaiter 
длл операнда, исполБЗОвавшегосл с await. Таким образом, операнд вообгце не 
облзан 6 б 1 тб обвектом Task; он может относитбсл к лгобому типу, содержагцему 
метод GetAwaiter. Пример моего собственного обвекта ожиданиц, свцзБшакзгцего 
конечнБ1и автомат async-.viCTO/m с инициируемБгм собБ1тием. 

public sealed class EventAwaiter<TEventArgs> : INotifyCompletion { 

private ConcurrentQueue<TEventArgs> m_events = new ConcurrentQueue<TEventArgs>(); 
private Action m_continuation; 

ttregion Членм, вшзмваемме конечнмм автоматом 

// Конечнши автомат сначала вћвшвает зтот метод длл полученив 

// обцекта ожиданив; возврацаем текуции обБект 

public EventAwaiter<TEventArgs> GetAwaiter() { return this; } 


продолжение # 
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// Сообшает конечному автоматуЈ произошли ли какие-либо собмтин 
public Boolean IsCompleted { get { return m_events.Count > 0; } } 

// Конечнши автомат сообшает, какои метод должен BbBbiBaTbca позднее; 

// сохранлем полученнун5 информацив 

public void OnCompleted(Action continuation) { 

Volatile.Write(ref m_continuation л continuation); 

} 

// Конечнши автомат запрашивает резулцтат, которшм нвлветсл 
// резулцтат оператора await 
public TEventArgs GetResult() { 

TEventArgs e; 

m_events.TryDequeue(out e); 
return e; 

} 

ttendregion 

// Теоретически может вмзшватвсл несколцкими потоками одновременно, 

// когда каждши поток инициирует собмтие 

public void EventRaised(Object sender, TEventArgs eventArgs) { 
m_events.Enqueue(eventArgs); // Сохранение EventArgs 

// длв возврашениа из GetResult/await 
// Если имеетсл незавершенное продолжение, поток забирает его 
Action continuation = Interlocked . Exchange(ref m_continuation, null); 
if (continuation != null) continuation(); // Продолжение вшполненил 
} // конечного автомата 

} 

Следуклции метод исполдзует мои класс EventAwaiter длл возврашенил из 
оператора await при инициировании собмтин. В данном случае конечнми автомат 
продолжает вмполнение при вмдаче исклгочении лгобмм потоком в домене. 

private static async void ShowExceptions() { 

var eventAwaiter = new EventAwaiter<FirstChanceExceptionEventArgs>(); 
AppDomain.CurrentDomain.FirstChanceException += eventAwaiter.EventRaised; 

while (true) { 

Console.WriteLine("AppDomain exception: {0}", 

(await eventAwaiter).Exception.GetType()); 

} 

} 

И наконец, пример кода, которми показмвает, как работает зта система: 

public static void Go() { 

ShowExceptions(); 

for (Int32 х = 0; х < 3; x++) { 
try { 

switch (х) { 
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} 


} 


} 

} 

catch 


case 0: throw 
case 1: throw 
case 2: throw 


{ } 


new InvalidOperationException(); 
new ObjectDisposedException(""); 
new ArgumentOutOfRangeException(); 


Асинхроннме функции 
и обработчики собмтии 

Асинхроннме функции обмчно исполБзугот тип возврашаемого значенин Task или 
Task<Result>, представлигогции завершение конечного автомата функции. Однако 
также возможно определение асинхроннои функции с возврагцаеммм типом void. Зто 
особми случаи, которми поддерживаетсл компилитором C# длл упрогценгш оченв 
распространеннои ситуации: реализации асинхронного обработчика собмтил. 

Почти все методм обработчиков собмтии имегот сигнатуру следугогцего вида: 

void EventHandlerCallback(Object sender, EventArgs e); 

Ha практике в обработчиках собмтии доволбно часто вмполннготсн операции 
ввода-вмвода — например, когда полБЗОвателБ гцелкает на злементе полБЗОвателБ- 
ского интерфеиса, что6бг открбгтб фаил и прочитатБ из него даннБге. Что6бг полбзо- 
вателБСКии интерфеис реагировал на деиствии полвзователн, ввод-вбшод должен 
вбшолннтбси асинхронно. Дли исполБЗОвангш такого кода в методе обработчика 
собвгтин с типом возврагцаемого значенгш void компилнтор C# должен разрешитв 
асинхроннБгм функцгшм иметБ возврагцаемБги тип void, чтобнг оператор await мог 
исполБЗОватБСн д./ш вБгполненин неблокиругогцих операции ввода-вБгвода. Когда 
асинхроннан функцин ггмеет возврагцаемвги тип void, компилитор генерирует код 
создангш конечного автомата, но не создает обвект Та s k, потому что он все равно не 
будет исполБЗОватБСи. По зтои причине невозможно узнатв, что конечнБги автомат 
асинхроннои функции, возврагцагогцеи void, отработал до завершенгш 1 . 


1 При попвгтке пометитБ клгочевБгм словом async точку входа программвг (Main) ком- 
пилнтор C# вБгдает сообпгение об ошибке. Если размеситБ операторБг await в методе Main, 
основнои поток процесса вернет управление из Main сразу же после вБшолненгш первого 
оператора await. А посколвку код, ВБгзБгвагогцеи Main, не может получитв обвект Task длл 
отслеживангш и ожиданил завершенгш, процесс просто завершитсн (из-за возврагценил 
управленгш из Main), а осталвнои код Main не будет вБгполнен. Компшштор C# считает 
подобнуго ситуацшо ошибкои и принимает меркг длл ее предотврагценгш. 
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Асинхроннме функции в FCL 

Лично мне моделБ асинхроннБ 1 х функции оченв симпатична, потому что ее до- 
волбно легко освоитб, она проста в исполБЗОвании и поддерживаетсл многими 
типами библиотеки FCL. Асинхроннвге функции сразу виднб 1 в коде, потому что 
по деиствугогцим соглашенгшм имн метода снабжаетсл суффиксом Async. В FCL 
многие типбг , предоставлнгогцие операцгш ввода-ввгвода, также предоставлигот 
методвг XxxAsync. Неско. п.ко примеров 1 : 

□ Все производнБге от System . 10. Stream клдссбг предоставлнгот методвг ReadAsync, 
WniteAsync, FlushAsync и CopyToAsync. 

□ Все производнБге от System . IO.textReader классБг предоставлигот методвг 
ReadAsync, ReadLineAsync, ReadToEndAsync и ReadBlockAsync. КлассБг, произ- 
воднБге от System . 10. TextWriter, предоставлигот методвг WriteAsync, Write- 
LineAsync и FlushAsync. 

□ Класс System . Net . Http . HttpClient предоставлиет методвг GetAsync, Get- 
StreamAsync, GetByteArrayAsync, PostAsync, PutAsync, DeleteAsync идр. 

□ Bce производнБгеот System.Net.WebRequest классБг (вклгочаи FileWebRequest, 
FtpWebRequest и HttpWebRequest) предоставлнгот методвг GetRequestStreamAsync 
и GetResponseAsync. 

□ Класс System . Data . SqlClient. SqlCommand предоставлиет методвг Ехе- 
cuteDbDataReaderAsync, ExecuteNonQueryAsync, ExecuteReaderAsync, 
ExecuteScalarAsync и ExecuteXmlReaderAsync. 

□ ИнструментБг (такие, как SvcUtil.exe), создагогцие типбг представителеи длн веб- 
служб, также генериругот методвг XxxAsync. 

Программистам с опбгтом исполБЗОвангш предвгдугцих версии .NET Framework 
могут 6 бгтб известнБг друггге модели асинхронного программировангш — как, напри- 
мер, моделБ, исполБЗОвавшан методвг BeginXxx и EndXxx в сочетании с интерфеисом 
IAsyncResult. Также имеетсн собБгтгшнан модслб, исполБЗОвавшан методвг XxxAsync 
(не возврагцагогцие о6б6ктбг Task) с вБгзовами методов обработчиков собвгтии при 
завершении асинхроннБгх операции. Зти две модели асинхронного программиро- 
вангш теперв считаготсл устаревшими, и вместо них рекомендуетси исполвзоватБ 
новуго моделв с обвектами Task. 

Просматриван описангш классов FCL, можно заметитв, что у некоторБгх классов 
нет методов XxxAsync, а вместо них предоставлнготсл методвг BeginXxx и EndXxx. 
В основном зто обБнсниетси тем, что у компании Microsoft не 6 бшо времени длн 


1 Методн WinRT поддерживагот те же соглашенил об именах и возвратагот интерфеис 
IAsyncInfo. К счаствго, .NET Framework поддерживает методм расширенил, которме пре- 
образугот IAsyncInfo в Task. Дополнителвнан информацил об исполБзовании асинхронннх 
WinRT API с асинхроннћши функцилми приведена в главе 25. 
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обновлешш зтих классов новмми методами. В будутцем зти классм будут дорабо- 
танм, и в них поивитсл полноценнан поддержка новои модели. А до того времени 
можно восполвзоватБСн вспомогателБНБш методом, адаптиругогцим старуго моделн 
BeginXxx/EndXxx длн новои модели на базе Task. 

Ранее л приводил код клиентского приложенгш, которое передает запрос по 
именованному каналу. Пора привести сервернуго сторону зтого кода. 

private static async void StartServer() { 
while (true) { 

var pipe = new NamedPipeServerStream(c_pipeName, PipeDirection.InOut, 1 , 
PipeTransmissionMode.Message, PipeOptions.Asynchronous | 

PipeOptions.WriteThrough); 

// Асинхроннни прием клиентского подклкЈченил . 

// ПРИМЕЧАНИЕ: NamedPipeServerStream исполБзует старут моделч 
// асинхронного программированил. 

// Р преобразук) ее к новои модели Task при помоци метода 
// FromAsync класса TaskFactory. 

await Task.Factory . FromAsync(pipe.BeginWaitForConnection, 
pipe.EndWaitForConnection, null); 

// Начало обслуживанил клиента; управление возврацаетсл немедленно, 

// потому что операцил ввтолнлетсл асинхронно. 

ServiceClientRequestAsync(pipe) ; 

} 

} 

В классе NamedPipeServerStream определенБ 1 методБ 1 BeginWaitForConnection 
и EndWaitForConnection, но еше не определен метод WaitForConnectionAsync. 

Ожидаетсл, что зтот метод будет добавлен в будугцеи версии FCL. Впрочем, как 
видно из предвгдугцего кода, и вБгзБгваго метод FromAsync класса TaskScheduler, 
передаго ему имена методов BeginXxx и EndXxx, а метод FromAsync создает обвект 
Task, которвш нвлиетси «оберткои» длн зтих методов. Теперв обвект Task можно 
исполвзоватБ с оператором await'. 

Длл старои со6бгтиинои модели программировангш в FCL нет вспомогателв- 
нБгх методов, адаптиругогцих зту моделв к новои модели на базе Task, позтому вам 
придетсл программироватБ их вручнуго. Следугогции код показвшает, как упако- 
ватБ обвект WebClient (исполБзугогции собБгтиинуго моделБ программировангш) 
с обвектом TaskCompletionSource, чтобвг длл него можно бвшо вБгзвгватБ await 
в асинхроннои функции. 

private static async Task<String> AwaitWebClient(Uri uri) { 

// Класс System.Net.WebClient поддерживает собмтиинук) моделБ 

продолжение # 

1 У метода FromAsync класса TaskScheduler имеготсл перегруженнне версии, получакнцие 
IAsyncResult, а также перегруженнБге версии, получагопгие делегатов длл методов BeginXxx 
и EndXxx. По возможности постараитесБ избегатБ версии с IAsyncResult, потому что они 
менее зффективнБГ 
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// асинхронного программированил 
var wc = new System.Net.WebClient(); 

// Создание обБекта TaskCompletionSource и его внутреннего обБекта Task 
var tcs = new TaskCompletionSource<String>(); 

// При завершении загрузки строки обћект WebClient инициирует 
// собмтие DownloadStringCompletedj завершашцее TaskCompletionSource 
wc . DownloadStringCompleted += (s, e) => { 
if (e.Cancelled) tcs.SetCanceled(); 
else if (e.Error != null) tcs.SetException(e.Error); 
else tcs.SetResult(e.Result); 

}; 


// Начало асинхроннои операции 
wc.DownloadStringAsync(uri); 

// Теперц Mbi можем взлтц обцект Task из TaskCompletionSource 
// и обработатц резулцтат обшчннм способом. 

String result = await tcs.Task; 

// Обработка строки резулцтата (если нужно)... 

return result; 

} 

Асинхроннне функции и исклк>ченич 

Если при обработке драивером устроиства асинхронного запроса что-то поидет не 
так, Windows нужно проинформироватБ об зтом приложение. К примеру, предста- 
вим, что при передаче баитов по сети произошел таим-аут. Если даннме не пришли 
вовремн, драивер устроиства сообгцает вам, что асинхроннан операцин завершиласБ 
с ошибкои. Длл зтого он отправлнет готовми IRP -пакет в CLR -пул потоков, а по- 
ток пула завершает обвект Task с исклкзчением. При возобновлении вмполненгш 
конечного автомата оператор await видит, что попмтка вмполненин операции бмла 
неудачнои, и вмдает исклгочение. 

В главе 27 и говорил о том, что обвектм Task обмчно иницииругот исклгочение 
AggregateException, а длл полученгш информации о реалгшмх исклгоченинх сле- 
дует обратитБСл к своиству InnerExceptions зтого исклгоченгш. Однако при ис- 
полБЗОвании await с Task вместо AggregateException ввгдаетсл первое внутреннее 
исклгочение 1 . Зто бвгло сделано длн того, чтобвг поведение кода соответствовало 
ожиданинм разработчика. Кроме того, без зтого вам пришлосБ 6 бг перехватБгватБ 
AggregateException в вашем коде, проверитв внутреннее исклгочение и либо пере- 
хватвгватБ его, либо вБгдаватБ заново. От зтого код становитсн слишком громоздким. 


i 


Длл лгобознателБНБГх: зто делает метод GetResult класса TaskAwaiter. 
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Если ваш метод конечного автомата сталкиваетсн с необработаннмм исклгоче- 
нием, то обвект Task, представлнгогции асинхроннуго функцшо, завершаетсн из-за 
необработанного исклгоченин. Лгобои код, ожидагогции завершенин зтого обвекта 
Task, <<увидит» зто исклгочение. Однако асинхроннан функцин также может иметБ 
возврагцаемБпг тип void; в зтом случае вБгзБшагогцан сторона не может обнаружитБ 
необработанное исклгочение. Таким образом, при вкгдаче необработанного исклгоченил 
асинхроннои функциеи, возврагцагогцеи void, сгенерированнБпг компилнтором код 
перехватит его и ввгдаст заново с исполБЗОванием контекста синхронизации сторонвг 
вБгзова (см. далее). Если сторона ввгзова исполннетсн в потоке графического интер- 
феиса, то исклгочение будет перезапугцено потоком графического интерфеиса. Обвшно 
повторное инициирование исклгочении приводит к завершениго всего процесса. 


Другие возможности асинхроннмх функции 

В зтом разделе речв поидет о некоторвгх дополиителБНБгх возможностлх асинхрон- 
нб 1 х функции. Поддержка отладки асинхроннБгх функции в Microsoft Visual Studio 
реализована просто замечателвно. Когда отладчик остановлен на операторе await, 
пошаговое вБшолнение (F10) осугцествллет переход в отладчик при достижении 
следугогцеи командвг после завершенгш операции. При зтом код может вбшолннтбсн 
даже в другом потоке, а не в том, которвш инициировал операциго! Такое поведеиие 
оченв удобно и сугцественно упрогцает отладку. 

Кроме того, при пошаговом вБшолнении с заходом (F1 1) в асинхроннуго функциго 
можно вбшти из функции, вернувшисБ на сторону вБгзова (Shift+F1 1); впрочем, зто 
должно 6бгтб сделано на открБшагогцеи фигурнои скобке асинхроннои функции. 
После ее прохожденгш комбинацгш Shift+F1 1 не будет работатк, пока асинхроннаи 
функцгш не отработает до завершенгш. Если вам потребуетсн отладитв ВБГЗБшагогции 
метод до того, как конечнБШ автомат отработает до завершенгш, установите точку 
прервшангш в вБгзвшагогцем методе и вклгочите код на ввшолнение (F5). 

НекоторБге асинхроннБге операцгш вбшолннготсн оченБ бБгстро, а, следователБно, 
завершаготсн почти мгновенно. В таких ситуацгшх незффективно приостанавливатБ 
конечнБШ автомат, чтобвг другои поток немедленно возобновил его ввшолнение; го- 
раздо зффективнее просто разрешитБ конечному автомату продолжитв вБшолнение. 
К счастБго, код, сгенерированнБш компиллтором длл оператора await, проверлет 
подобнвге ситуации. Если асинхроннан операцгш завершаетсл непосредственно 
перед возвратом управленгш из потока, поток не возврагцает управление, а просто 
вБшолннет следугогцуго строку кода. 

Все зто, конечно, хорошо, но времн от времени попадаготсн асинхроннвге функ- 
ции, которкге вБшолннгот значителБНБге вБгчисленгш перед запуском асинхроннои 
операцгш. Если вбгзвитб такуго функциго из потока графического интерфеиса вашего 
прнложенгш, ннтерфеис перестанет реагнроватв на деиствгш полвзователн. А еслн 
асинхроннан операцгш завершаетсл синхронно, то полБЗОвателБСКгш интерфеис 
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будет недоступен в течение eme болћшего времени. Таким образом, если вм хотите 
инициироватБ асинхроннуго функцшо из другого потока, исполћзуите статическии 
метод Run класса Task: 

// Task.Run BbBbiBaeTcn в потоке графического интерфеиса 
Task.Run(async () => { 

// Зтот код внполннетсв в потоке из пула 
// TODO: Подготовителинме вмчисленил... 

await XxxAsync(); // Инициирование асинхроннои операции 
// Продолжение обработки... 

}); 

В зтом коде продемонстрирована егце одна полезнан возможностб С#: асинхроннБге 
лимбда-вБфаженгш. Дело в том, что оператор awat нелвзи просто поместитБ в тело 
обвшного лнмбда-вБфаженин, потому что компилнтор не сможет преобразоватБ метод 
в конечнвш автомат. Размегцение async перед лимбда-вБфажением заставит компи- 
лнтор преобразоватв лнмбда-вБфажение в метод конечного автомата, возврагцагогции 
значение Task или Task<TResult>, которое может 6бгтб присвоено лгобои делегатнои 
переменнои Func с типом возврагцаемого значенгш Task или Task<TResult>. 

При написании кода оченв легко вбгзвлтб функциго async, забкгв об исполбзо- 
вании оператора await: 

static async Task OuterAsyncFunction() { 

InnerAsyncFunction(); // B атои строке пропуцен оператор await! 

// Код продолжает внполннтцсл, как и InnerAsyncFunction ... 

} 

static async Task InnerAsyncFunction() { /* ... */ } 

K счастБго, в таких ситуацгшх компшштор C# ввгдает предупреждение и пред- 
лагает применитБ оператор await к резулктату вБгзова. Зто хорошо, но в отделвнБгх 
случанх вас деиствителвно не интересует, когда завершитсл InnerAsyncFunction, 
и вб1 6бг предпочли исполБЗОватБ зтот код без предупреждении компилнтора. Чтобкг 
избавитБСн от предупрежденгш, просто присвоите переменнои обвект Task, возвра- 
гценнБш InnerAsyncFunction. В далБнеишем переменнуго можно игнорироватБ 1 . 

static async Task OuterAsyncFunction() { 

var noWarning = InnerAsyncFunction(); // Строка без await 

// Зтот код продолжает виполнлтцсв, как и код InnerAsyncFunction ... 

} 

А н предпочитаго определитБ метод расширенгш, которБш вбгглндит так: 

[MethodImpl(MethodImplOptions . Aggressivelnlining) ] // Заставллет компилвтор 

// убратц Bbi30B при оптимизации 

public static void NoWarning(this Task task) { /* He содержит кода */ } 


1 K счастмо, компиллтор не вндает предупрежденгш о том, что локалћнал переменнал не 
исполБзуетсл в программе. 
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Далее метод исполћзуетсл следугошим образом: 

static async Task OuterAsyncFunction() { 

InnerAsyncFunction().NoWarning(); // Строка без await 

// Код продолжает внполнптвсЛј как и InnerAsyncFunction ... 

} 

У асинхроннмх операции ввода-вмвода ссп> одна деиствителБно замечателБнан 
особенностћ: вм можете инициироватћ сразу несколБКО операции, чтобм они вм- 
полннлисв параллелБно. Зто может обеспечитБ феноменалБНБ1и прирост произво- 
дителБности приложешш. И eme нигде не приводил код, которБш запускает мои 
сервер именованного канала, а затем обрагцаетсл к нему с клиентскими запросами. 
Вот как он вбгглндит: 
public static async Task Go() { 

// Запуск сервера немедленно возврацает управление, потому что 
// сервер ожидает клиентские запросм в асинхронном режиме 
StartServer(); // Возврацает void, компиллтор вмдает предупреждение 

// Создание набора асинхронних клиентских запросов; 

// сохранлем Task<String> каждого клиента. 

List<Task<String>> requests = new List<Task<String>>(10000) ; 
for (Int32 n = 0; n < requests.Capacity; n++) 

requests.Add(IssueClientRequestAsync("localhost", "Request #" + n)); 

// Асинхронное ожидание завершенил всех клиентских запросов 
// ВНИМАНИЕ: если 1+ задании вшдадут исклгачение, 

// 1/JhenAll заново инициирует последнее исклмгчение 
String[] responses = await Task.WhenAll(requests); 

// Обработка всех запросов 

for (Int32 n = 0; n < responses.Length; n++) 

Console.WriteLine(responses[n]); 

} 

Код запускает сервер именованного канала, что 6 б 1 он начинал прослушивание 
клиентских запросов, а затем в цикле for инициирует 10 000 запросов с макси- 
малБно возможнои скоростБГО. При каждом вБгзове IssueClientRequestAsync 
возврагцаетсл обвект Task<String>, которћги добавлнетсл в коллекциго, ТеперБ 
сервер именованного канала с максималБно возможнои скоростБГО обрабатћшает 
зти запросБц исполБзун потоки из пула, которБШ пБгтаготсн обеспечитБ максималБ- 
нуго загрузку всех процессоров на машине 1 . По мере того, как сервер обрабатвшает 
каждБш запрос, обвект Task<String> каждого запроса завершаетсл со строковвш 
ответом, возврагценнБш сервером. 


1 Заннтное наблгодение: когда л тестировал зтот код на своеи машине, загрузка процессора 
на моем 8-процессорном компвготере, естественно, доходила до 100 %. Так как все процес- 
сорм бнли заннтн, машина нагреваласв, и шум от вентиллтора становилсл силћнее! После 
завершенил обработки загрузка процессора снижаласБ, и вентиллтор тоже затихал. 
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В 1фсд|)|ду riLC.vi коде и хотел дождатћсл полученин ответов на все клиентские 
запросм, прежде чем переходитБ к обработке резулћтатов. Длл зтого и вБ 13 Б 1 вал 
статическии метод WhenAll класса Task. Во внутреннеи реализации представлении 
зтот метод создает обвект Т а sk<St ning [ ] >, которвш завершаетсл после завершенин 
всех обвектов Task из коллекции List. Затем оператор await ввшБшаетсн длн обв- 
екта Task<Stning [ ] >, что6б 1 конечнБш автомат продолжил работу после ввшолне- 
нии всех задач. И последователвно перебираго ответБ1 и обрабатБшаго их (вмзБшан 
Console.WniteLine). 

Возможно, вб1 захотите обработатБ каждБШ запрос по мере поступленин — вместо 
того, что6б1 дожидатБСи их завершенгш. Зта задача решаетси почти так же просто 
при помогци статического метода WhenAny класса Task. Обновленнан версин кода 
ВБ 1 ГЛЛДИТ так: 

public static async Task Go() { 

// Запуск сервера немедленно возврацает управление, потому что 
// сервер ожидает клиентские запроа >1 в асинхронном режиме 
StartServer(); 

// Создание набора асинхроннух клиентских запросов; 

// сохранлем Task<String> каждого клиента. 

List<Task<String>> requests = new List<Task<String>>(10000) ; 
for (Int32 n = 0; n < requests.Capacity; n++) 

requests.Add(IssueClientRequestAsync("localhost"j "Request #" + n)); 

// Продолжение c завершением КАЖДОИ задачи 
while (requests.Count > 0) { 

// ПоследователБнаа обработка каждого завершенного ответа 

Task<String> response = await Task.WhenAny(requests); 

requests.Remove(response); // Удаление завершеннои задачи из коллекции 

// Обработка одного ответа 
Console . WriteLine(response.Result) ; 

} 

} 

Здссб н создаго цикл while, перебирагогции клиентские запросБт В цикле оператор 
await вБИБшаетсн длн метода WhenAny класса Та sk, которБпт возврагцает один обвект 
Task<Stning> длн клиентского запроса, обработанного сервером. После полученгш 
обвекта Task<Stning> н исклгочаго его из коллекцгш, а затем запрашиваго резулвтат 
дли обработки (передачи Console .WniteLine). 


Потоковне модели приложении 

В .NET Framework поддерживаготси разнообразнБге модели приложении, каждал 
из которкгх может предложитБ собственнуго потоковуго моделв. КонсолБНБге при- 
ложенгш и Wi n < Iо \vs -с. : iy жб i>i (которпге фактически тоже нвлиготсл консолбнбгми 
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приложенинми, просто вм не видите консолб) не навнзмвагот никакои потоковои 
модели; то естБ поток может делатБ все, что он хочет и когда хочет. 

Однако приложенил с графическим полБЗОвателБСКим интерфеисом (GUI), 
в том числе приложешга Windows Forms, Windows Presentation Foundation (WPF), 
Silverlight и Windows Store, предлагагот такуго моделв, в которои обновлитв окно 
можно толбко создавшему его потоку. GUI -потоки обвгано порождагот асинхроннвге 
операции, что6б1 предотвратитБ блокировку и не допуститв отсутствин реакции 
интерфеиса на средства полвзователБСКого ввода — мбшњ, клавиатуру, перо, сенсор- 
нбш зкран. Однако при завершении асинхроннои операции поток пула завершает 
оођскт Task, возобновлнн работу конечного автомата. 

Длл некоторв1х приложении такое поведение нормалвно и даже желателнно, 
потому что оно зффективно. Но длн других моделеи приложении (например, 
приложении с графическим интерфеисом) оно создает проблемБр потому что код 
вБвдает исклгочение при попБ1тке обновленгга злементов полвзователБСКого интер- 
феиса через поток из пула. Иногда последнии должен каким-то образом заставитк 
графическии поток обновлнтБ злементБг полБЗОвателБСКого интерфеиса. 

Приложенгга ASP.NET позволигот лгобому потоку делатв все, что угодно. Начав 
обрабатвшатБ клиентскии запрос, поток пула может внгбратБ полБЗОвателБСКие 
регионалБНБге стандартБг (Sy stem . Globalization . Culturelnf о), позволив серверу 
осугцествитБ приннтБге в рассматриваемом регионе форматвг чисел, дат и времени 1 . 
Также веб-сервер может определитв идентификационнвге даннвге клггента (System . 
Security . Pnincipal . IPrincipal), предоставив ему доступ толбко к тем ресурсам, 
на которкге у него естБ права. Порожденнаи одним потоком пула асинхроннаи опе- 
рацгга заканчиваетсн другим потоком, которвш обрабатвшает ее резулБтат. Хотн зта 
работа и вБшолннетсн по поручениго клггентского запроса, регионалБНБге стандартБг 
и идентификационнБге даннБге клиента должнбг <<переходитБ» к новому потоку пула, 
чтобвг всн работа, ввшолннеман по поручениго клиента, исполБЗОвала регионалБнвге 
стандартБг и идентификационнуго информациго клиента. 

К счастБго, в FCL определен базоввш класс System . Threading . Synchronization - 
Context, позволнгогции решитв все описаннБге проблемБк Обвект, производнБпг от 
зтого класса, свнзБшает прикладнуго моделк с потоковои. В FCL имеетси группа 
классов, производнБгх от класса SynchronizationContext, но обкгано напрнмуго 
они не исполБзуготсл; более того, многие из них даже не документированБг. 

В основном разработчикам приложении не нужно ничего знатв о клас- 
се SynchronizationContext. При вкгзове await длл Task исполБзуетсл обвект 
SynchronizationContext вБгзБшагогцего потока. Когдапул потоказавершает обвект 
Task, исполБзуетсн обвект SynchronizationContext, обеспечивагогции соответствгге 
потоковои и прикладнои модели. Таким образом, когда GUI -поток ввшолниет 
await длл Task, код, следугогцгш за оператором await, заведомо будет исполнен 
в GUI -потоке, что позволлет зтому коду обновитв злементБ! полБЗОвателБСКого 


1 ДополнителБнал информацил по даннои теме находитсл по адресу http://msdn.microsoft. 
com/ru-ru/library/bz9tc508.aspx. 
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интерфеиса. Длн приложении ASP.NET код, следукпции за оператором await, за- 
ведомо вмполннетсл в пуле потока, с котормм свнзанм регионалБнме стандартм 
и идентификационнме даннме клиента. 

В бо. ; п.пшпст1«' случаев возобновление работм конечного автомата с исполпзо- 
ванием потоковои модели приложенгш чрезвмчаино полезно и удобно. Впрочем, 
в отделБнмх случанх оно способно создатБ проблемБт Следугогции пример вБгзБшает 
взаимнуго блокировку приложенгш WPF: 

private sealed class MyWpfWindow : Window { 

public MyWpfWindow() { Title = "WPF Window"; } 

protected override void OnActivated(EventArgs e) { 

// Запрос своиства Result не позволлет GUI -потоку вернутв управление; 

// поток блокируетсл в ожидании резулвтата 

String http = GetHttp( ). Result; // Синхронное получение строки 
base.OnActivated(e) ; 

} 

private async Task<String> GetHttp() { 

// Видача запроса HTTP и возврат из GetHttp 
HttpResponseMessage msg = await new 

HttpClient().GetAsync("http://Wintellect.com/"); 

// B зту точку mn никогда не попадем: GUI -поток ожидает завершенил 
// зтого метода, а метод не может завершитвсл, потому что GUI -поток 
// ожидает его завершенип > ВЗАИМНАЛ БЛОКИРОВКА! 

return await msg.Content . ReadAsStringAsync( ); 

} 

} 

Разработчики, создагогцие библиотеки классов, определенно должнб 1 знатБ о клас- 
се SynchronizationContext. Зто позволит им создаватв вБ1СокопроизводителБНБш 
код, работагогции со всеми моделнми приложении. Так как болвшал частБ библио- 
течного кода не зависит от модели приложенгш, нам хотелосв 6 bi избежатБ допол- 
нителБшлх затрат, свнзаннБ1х с исполБЗОванием обвекта SynchronizationContext. 
Кроме того, разработчики библиотек классов должнб 1 сделатБ все возможное, что 6 б 1 
помочб разработчикам приложении избежатк ситуации взаимнои блокировки. 
Длн решенгш обеих проблем класср.1 Task и Task<TResult> предоставлнгот метод 
Conf igureAwait с сигнатурои следугогцего вида: 

// Task определпет метод: 
public ConfiguredTaskAwaitable 

ConfigureAwait(Boolean continueOnCapturedContext); 

// Task<TResult> определпет метод: 
public ConfiguredTaskAwaitable<TResult> 

ConfigureAwait(Boolean continueOnCapturedContext); 

При передаче true метод ведет себл так, как если 6 bi он вообгце не ввкзвал- 
сл. Но если передатв значение f alse, то оператор await не запрашивает обп.ект 
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SynchronizationContext вмзмвакицего потока, а когда поток пула завершает за- 
дание Task, то происходит простое завершение с вмполнением кода после оператора 
await через поток пула. 

Хотл Moii метод GetHttp не входит в библиотеку классов, проблема взаимнои 
блокировки исчезает при добавлении вмзовов Conf igureAwait. Измененнан версип 
метода GetHttp вмгллдит так: 

private async Task<String> GetHttp() { 

// Вндача запроса НТТР и возврат из GetHttp 
HttpResponseMessage msg = await new 

HttpClient().GetAsync("http://Wintellect.com/") 

.ConfigureAwait(false); 

// Ha зтот раз управление попадет в зту точку, потому что поток пула 
// может вуполнитб зтот код (в отличие от внполненил через GUI -поток). 

neturn await msg.Content.ReadAsStringAsync().ConfigureAwait(false); 

} 

Как показмвает предмдугции код, вмзов ConfigureAwait(false) должен 6 мтб 
применен к каждому обвекту Task, исполћзуемому с await. Зто свнзано с тем, что 
асинхроннБШ операции могут завершатБСи синхронно, и когда зто происходит, bki- 
ЗБшагогции поток просто продолжает вбшолнитбси без возврагценгш управленгш 
стороне ввгзова; вбг никогда не знаете, какои операции потребуетсн игнорироватБ 
oo'bCKT SynchronizationContext, позтому необходимо приказатБ всем операцгшм 
игнорироватБ его. Зто также означает, что код библиотеки классов должен 6 бгтб 
независимБш от модели приложенгш. 

Также можно переписатБ метод GetHttp так, как показано ниже, чтобкг все bbi- 
полнение происходило через поток пула: 

private Task<String> GetHttp() { 
return Task.Run(async () => { 

// Виполнение в потоке пула, с которим не свлзан 
// обБект SynchronizationContext 
HttpResponseMessage msg = await new 

HttpClient().GetAsync("http://Wintellect.com/"); 
return await msg.Content.ReadAsStringAsync(); 

}); 

} 

Обратите внимание: в зтои версии кода метод GetHttp не нвлнетсл асинхроннои 
функциеи; н удалил клгочевое слово async из сигнатурБ1 метода, потому что метод 
более не содержит оператор await. С другои сторонБц лимбда-вБфажение, пере- 
даваемое Task . Run, нвлнетсл асинхроннои функциеи. 


Асинхроннал реализацил сервера 

Многолетнее обгцение с множеством разработчиков показало, что лишб оченБ 
немногие из них знагот о встроеннБгх средствах ,NET Framework, позволнгогцих 
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строитБ асинхроннБ 1 е серверБ 1 с хорошеи масштабируемостБнз. В зтои книге н не 
смогу о6ђиснитб, как зта задача решаетсл длн каждого вида серверов, но могу хотн 
6bi указатБ, что следует искатБ в документации MSDN. 

□ Построение асинхроннмх приложении Web Forms ASP.NET: добавБге в фаиле 
.aspx строку «Async=true» в директиве page и ознакомБтесБ с описанием метода 
RegisterAsyncTas k класса System . Web.UI.Page. 

□ Построение асинхроннмх MVC -контроллеров ASP.NET: обЂивите класс 

контроллера производнБш от System.Web.Mvc . AsyncController и верните 
Task<ActionResult> из метода деиствин. 

□ Построение асинхронного обработчика ASP.NET: обЂнвите класс производнБш 
от System . Web . HttpTas kAsyncHandler и переопределите его абстрактнБш метод 
ProcessRequestAsync. 

□ Построение асинхроннои службм WCF: реализуите службу как асинхроннуго 
функциго, возврагцагогцуго Task или Task<TResult>. 


Отмена операции ввода-вмвода 

В обгцем случае Windows не предоставлиет возможности отменБ 1 затннувшеисн опе- 
рации ввода-вБшода. Многие разработчики хотели 6 bi видетБ такуго возможностб, но 
реализоватБ ее достаточно сложно. ВедБ если вб 1 обрагцаетесБ с запросом к серверу, 
а потом решаете, что ответ вам болБше не нужен, просто приказатБ серверу проиг- 
норироватБ исходнбп! запрос уже не удастсл; нужно приннтБ баитБ1 на клиентскои 
машине и отброситБ их. Кроме того, возникает ситуации гонки — запрос на отмену 
может поступитБ в то времи, когда сервер передает ответ. И как должно поступитБ 
ваше приложение? Вам придетсл обработатБ зту потенциалБнуго ситуациго в своем 
коде и решитБ, то ли проигнорироватБ даннБ1е, то ли обработатБ их. 

Дли упрогценин зтои задачи и рекомендуго реализоватБ метод расширенин 
WithCancellation, которБпг расширнет Task<TResult> (вам также понадобитсл 
аналогичнан перегрузка, расширнгогцаи Task) следугогцим образом: 

private struct Void { } // Из-за отсутствил необоб[ценного класса 
// TaskCompletionSource. 

private static async Task<TResult> 

WithCancellation<TResult>(this Task<TResult> originalTask, 

CancellationToken ct) { 

// Создание обнекта Task, завершаемого при отмене CancellationToken 
var cancelTask = new TaskCompletionSource<Void>(); 

// При отмене CancellationToken завершитн Task 
using (ct.Register( 



Отмена операции ввода-вивода 815 


t => ( (TaskCompletionSource<Void>)t).TrySetResult(new Void()), 
cancelTask)) { 

// Создание обкекта Taskj завершаемого при отмене исходного 

// обБекта Task или обиекта Task от CancellationToken 

Task апу = await Task.WhenAny(originalTaskj cancelTask.Task); 

// Если какои-либо обиект Task завершаетсл из-за CancellationTokenj 
// инициироватБ OperationCanceledException 

if (апу == cancelTask.Task) ct.ThrowIfCancellationRequested(); 

} 

// Вшполнитц await длв исходного заданив (синхронно); awaiting it 
// если произоидет ошибкаЈ вшдатц первое внутреннее исклшчение 
// вместо AggregateException 
return await originalTask; 

} 

Теперц зтот метод расширении вмзмваетси следукдцим образом: 

public static async Task Go() { 

// Создание обцекта CancellationTokenSourcej отменлкицего себн 

// через заданнши промежуток времени в миллисекундах 

var cts = new CancellationTokenSource(5000); // Чтобш отменитц ранее, 

var ct = cts.Token; // вшзовите cts.Cancel() 

try { 

// R исполизу 10 Task.Delay длн тестированив; замените другим методом, 

// возврашакнцим Task 

await Task.Delay(10@00).WithCancellation(ct); 

Console.WriteLine("Task completed"); 

} 

catch (OperationCanceledException) { 

Console.WriteLine("Task cancelled"); 

} 

} 

Некоторме операции ввода-вмвода 
ДОЛЖНМ BbinO/IHBTbCB синхронно 

В Win32 API сутцествует множество функции, вмполннкзших операции ввода-вм- 
вода. К сожаленшо, не все их них допускагот асинхронное вмполнение. К примеру, 
\\тп32-метод CreateFile (вмзмваемми конструктором FileStream) всегдавмпол- 
ннетсл синхронно. При попмтке создатБ или открмтБ фаил на сервере в сети до воз- 
врагцешш управленин методом CreateFile может проити несколБКО секунд — в зто 
времн вмзмвагогции поток ничего не делает. В идеале приложенгш, разработаннме 
с прицелом на оптималБнме производителБностБ и масштабируемостБ, должнб 1 ис- 
полБЗОватБ \\чп32-фу|1КЦ1по, котораи создает или открБ1вает фаил в асинхронном 
режиме, что 6 б 1 поток не ждал ответа с сервера. К сожалениго, в Win32 нет функ- 
ции, подобнои CreateFile, а, значит, FCL не предлагает зффективного средства 
асинхронного открБ1тил фаилов. Windows также не предоставлнет функции длл 
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асинхронного обрагценгш к реестру, обрагценгш к журналу собмтии, полученил 
списка фаилов/подкаталогов, измененгш атрибутов фаила/каталога и т. д. 

Рассмотрим ситуацшо, когда такое поведение становитсн серћезнои проблемои. 
Представете, что вам нужно написатБ простои злемент интерфеиса длп ввода пути 
к фаилу и поддержкои автоматического завершенгш (примерно как в часто исполб- 
зуемом диалоговом окне открБгтгш фаила). Зтот злемент управленгш должен задеи- 
ствоватБ отделБНБге потоки длл перебора папок, в которвгх осугцествлнетсл поиск 
фаилов, так как в Windows не сугцествует функцни асинхронного перебора фаилов. 
По мере того как полвзователБ продолжает вводитб путБ к фаилу, вам придетсл 
подклгочатв дополнителБНБге потоки, игнорирул резулктатБг ранее порожденннгх 
потоков. В Windows Vista попвиласБ нован Win32-(})yuia[ii м CancelSynchronousIO. 
Она позволнет одному потоку отменптв синхроннуго операциго ввода-вБгвода, прово- 
димуго другим. Зта функцгш не отражена в FCL, но если вбг решите восполБЗОватБСн 
его ггз управлнемого кода, ввгзовите ее пргг помогци механггзма P/Invoke. Сигнатура 
P/Invoke дли данного случаи рассмотрена в следугогцем разделе. 

Многгге полагагот, что с синхроннБгм прггкладнБгм программнБгм интерфеисом 
работатБ прогце, и во многггх случалх зто деиствителБно так. Но ггногда именно 
синхроннБге ггнтерфеисБг сгглбно осложннгот жггзнб. 

Из-за проблем, возникагогцих пргг синхронном вБгполнении операции ввода-вБг- 
вода, пргг проектггровангги Windows Runtime группа Windows решггла предоставитв 
все методвг ввода/вБгвода в асггнхроннои форме. Такггм образом, сеичас сугцествует 
функцгш Windows Runtime API длн асггнхронного открвгтгш фаилов (см. описание 
метода OpenAsync класса Windows.Storage.StorageFile). Windows Runtime не 
представллет функции API дли синхронного вБгполненин операцгги ввода/вБгво- 
да. К счаствго, пргг вБгзове зтих функции можно восполвзоватБСл асинхроннБгми 
функцгшми C# длн упрогценин кода. 


Проблемм FileStream 

При создании обвекта FileStream флаг FileOptions . Asynchronous позволнет ука- 
затв, какгге операции — сггнхроннБге илгг асинхроннБге — будут ггсполБЗОватБСи длн 
взаимодеиствип (что зквивалентно ввгзову Win32-())ymainn CreateFile и передаче 
еи флага FILE_F LAG_OVERLAPPED). Пргг отсутствии зтого флага Windows вБгполннет 
все операцни с фаилом в синхронном режггме. Разумеетсл, нггчто не мешает ввгзватБ 
метод ReadAsync обвекта FileStream. С точкгг зренггн приложенин зто вбгглндит как 
асггнхронное вБгполненгге операцгги, но на самом деле класс FileStream змулггрует 
асггнхронное поведение пргг помогци дополнителБного потока, которкги впустуго 
тратит ресурсвг и снижает проггзводителБностБ. 

В то же времп можно создатв обвект FileStream, указав флаг FileOptions . 
Asynchronous. После зтого вбг можете вбгзвлтб метод Read обвекта FileStream длн 
вБгполненин сггнхроннои операции. Класс FileStream змулирует такое поведение, 
запускан асннхроннуго операцнго н немедленно переводн вБгзБгвагогцнн поток в спн- 
гцгги режггм до завершенгш операцгггг. Зто тоже не самвги зффектггвнБги способ, но он 
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лучше, чем вмзов метода BeginRead с применением обвекта FileStream, созданного 
без флага FileOptions . Asynchronous. 

Подведем итоги. При работе с обвектом FileStream следует заранее вмбратБ, 
синхроннБ1м или асинхроннБ1м будет ввод-вбшод фаилов, и установитв флаг 
FileOptions . Asynchronous (или не делатБ зтого). Если флаг установлен, всегда 
вБ 13 Б 1 ваите метод ReadAsync, а если нет — метод Read. Зто обеспечит наилучшуго 
производителБностБ. Если вб1 собираетесБ вбшолнитб синхроннуго или асинхроннуго 
операциго с обвектом FileStream, зффективнеи всего конструироватв даннБШ о6ђ- 
ект с флагом FileOptions . Asynchronous. В качестве алвтернативБ1 можно создатБ 
два обвекта FileStream дли одного фаила. Один обвект FileStream будет открвгг 
длл асинхронного ввода-ввшода, второи — длл синхронного. Учтите, что класс 
System.IO.File содержит вспомогателБНБге методБ1 (Create, Open и OpenWrite), 
которБ1е создагот и возврагцагот о6ђсктб1 FileStream. Во внутреннеи реализации 
ни один из зтих методов не исполвзует флаг FileOptions . Asynchronous, позтому 
длл построенгш масштабируемнгх приложении с хорошим временем отклика от 
зтих методов лучше держатвси подалБше. 

Следует также помнитб, что драивер устроиства фаиловои системвг NTFS вбг- 
полниет noKOTopbic операции в синхронном режиме вне зависимости от способа 
открвгтгш фаила. ДополнителБнуго информациго по зтои теме вбг наидете по адресу 
http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B1 56932. 


Приоритетм запросов ввода-внвода 

В главе 26 бвшо показано, каким образом приоритет потока влгшет на способ его 
исполненгш. Однако сами потоки также вбшолннгот запросБг ввода-вБгвода к раз- 
ЛИЧНБ1М аппаратнБгм устроиствам дли чтенгш и записи даннвгх. Если времн про- 
цессора окажетсн ввгделено под запросвг с низким приоритетом, в очереди оченв 
бБгстро окажутсн сотни и даже тбгснчи запросов. Так как длн их обработки требуетсн 
времи, скорее всего, поток с низким приоритетом повлилет на бвгстродеиствие 
системБг, приостановив более приоритетнБге потокгг. Именно позтому можно 
наблгодатБ снижение бБгстродеиствгш компвготера пргг вБгполненгггг длителБНБгх 
нггзкопрггорггтетнБгх задангги, таких как дефрагментацгш диска, сканирование на 
вггрусБг, ггндексггровангге содержимого гг т. п. 1 

Windows позволнет указатв прггоритет потока пргг вБгполненгггг запросов ввода- 
вБгвода. За дополнителБнои ггнформациеи обрагцаитесБ к статке по адресу http://www. 
microsoft.com/whdc/driver/priorityio.mspx. К сожаленггго, даннаи функцггоналБностБ 
егце не вклгочена в FCL; надегосв, она понвггтсн в следугогцеи версгггг. Однако пре- 
ггмугцеством даннои функцгггг уже можно восполБЗОватБСи пргг помогци механггзма 
P/Invoking. Вот как вбггллдггт такои код: 


1 Windows-^yHK4iia SuperFetch исполБзует низкоприоритетнБге запросБГ ввода-вБ1вода 
в своих интересах. 
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internal static class ThneadlO { 

public static BackgroundProcessingDisposer BeginBackgroundProcessing( 
Boolean process = false) { 

ChangeBackgroundProcessing(process, true); 
return new BackgroundProcessingDisposer(process); 

} 

public static void EndBackgroundProcessing(Boolean process = false) { 
ChangeBackgroundProcessing(process, false); 

} 

private static void ChangeBackgroundProcessing( 

Boolean process, Boolean start) { 

Boolean ok = 

process ? SetPriorityClass(GetCurrentWin32ProcessHandle(), 

start ? ProcessBackgroundMode.Start : ProcessBackgroundMode.End) 

: SetThreadPriority(GetCurrentWin32ThreadHandle(), 
start ? ThreadBackgroundgMode.Start : ThreadBackgroundgMode.End); 
if (!ok) throw new Win32Exception(); 

} 

// Зта структура позволпет инструкции using вмити 
// из режима фоновои обработки 

public struct BackgroundProcessingDisposer : IDisposable { 
private readonly Boolean m_process; 
public BackgroundProcessingDisposer( 

Boolean process) { m_process = process; } 
public void Dispose() { EndBackgroundProcessing(m_process); } 

} 

// См. Win32-^yHKUHH THREAD_MODE_BACKGROUND_BEGIN 
// и THREAD_MODE_BACKGROUND_END 

private enum ThreadBackgroundgMode { Start = 0x10000, End = 0x20000 } 

// См. Win32-^yHKUHH PROCESS_MODE_BACKGROUND_BEGIN 
// и PROCESS_MODE_BACKGROUND_END 

private enum ProcessBackgroundMode { Start = 0x100000, End = 0x200000 } 

[DllImport("Kernel32", EntryPoint = "GetCurrentProcess", 

ExactSpelling = true)] 

private static extern SafeWaitHandle GetCurrentWin32ProcessHandle(); 

[DllImport("Kernel32", ExactSpelling = true, SetLastError = true)] 
[return: MarshalAs(UnmanagedType.Bool)] 
private static extern Boolean SetPriorityClass( 

SafeWaitHandle hprocess, ProcessBackgroundMode mode); 

[DllImport( 

"Kernel32", EntryPoint = "GetCurrentThread", ExactSpelling = true)] 
private static extern SafeWaitHandle GetCurrentWin32ThreadHandle(); 

[DllImport("Kernel32", ExactSpelling = true, SetLastError = true)] 

[return: MarshalAs(UnmanagedType.Bool)] 

private static extern Boolean SetThreadPriority( 
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SafeWaitHandle hthread, ThreadBackgroundgMode mode); 

// http://msdn.microsoft.com/en-us/library/aa480216.aspx 
[DllImport( 

"Kernel32", SetLastError = true, EntryPoint = "CancelSynchronousIo")] 

[return: MarshalAs(UnmanagedType.Bool)] 

private static extern Boolean CancelSynchronousIO(SafeWaitHandle hThread); 

} 

Следукдции код показмвает, как все зто исполћзоватБ: 

public static void Main () { 

using (ThreadlO.BeginBackgroundProcessing()) { 

// Здесв располагаетсп низкоприоритетнни запрос ввода-вмвода 
// (например, вмзов BeginRead/BeginWrite) 

} 

} 

Вм обЂлснлете Windows, что поток должен вмполнитђ низкоприоритетнме запро- 
см ввода-вмвода при помопда метода BeginBackgroundProcessing класса ThreadlO. 
Обратите внимание, что при зтом также снижаетсн приоритет вмполненин потока 
процессором. ВернутЂ поток к вмполненшо запросов ввода-вмвода обмчнои важ- 
ности (и к обмчному приоритету вмполненин потока процессором) можно методом 
EndBackgroundProcessing или же вмзвав метод Dispose длн значенин, возврашен- 
ного методом BeginBackgroundProcessing (при помогци инструкции using нзмка 
С#, как показано в примере). Поток может влиитђ толђко на собственнми режим 
фоновои обработки; Windows не позволнет одному потоку менитЂ режим фоновои 
обработки другого потока. 

Чтобм заставитЂ все потоки в процессе обрабатмватЂ низкоприоритетнме 
запросм ввода-вмвода и снизитђ приоритет вмполненгш потоков процессором, 
можно вмзватЂ метод BeginBackgroundProcessing, передав ему значение true 
длл параметра process. Процесс может воздеиствоватБ толбко на собственнми 
фоновми режим обработки; Windows не позволиет потоку меннтБ фоновми режим 
обработки другого процесса. 

ВНИМАНИЕ 

В сферу ответственности разработчика входит применение новмх фоновнх при- 
оритетов, обеспечиваклцих более вмсокое бмстродеиствие активнмх приложении, 
и принлтие мер длл устраненил инверсии приоритетов. При наличии активнмх опе- 
рации ввода-вб 1 вода с обвннмм приоритетом поток, работакхции в фоновом режиме, 
может получаљ резулитатм запросов ввода-вмвода с задержкои в несколико секунд. 
Если поток с низким приоритетом в рамках синхронизации потоков получит право 
на блокировку, ожидаемое потоком с обмчнмм приоритетом, последнии может 
оказатиси в ожидании окончанил обработки низкоприоритетнмх запросов ввода- 
вмвода. Длл возникновенил проблеми! потоку с фонови 1 м приоритетом не придетсл 
даже отправллти запросм на ввод-вмвод. Позтому следует свести к минимуму со- 
вместное исполизование обЂектов синхронизации потоками с обнчнмм и фонови1м 
приоритетами (а лучше вообиде зтого избегати). Зто избавит вас от инверсии при- 
оритетов, при которои потоки с обмчнмм приоритетом перестакзт вмполнлтисл из-за 
блокировок, установленнмх потоками с фонови 1 м приоритетом. 


Глава 29. ПримитивнБ 1 е 
конструкции синхронизации 
потоков 


Когда поток из пула блокируетси, пул порождает дополнителмше потоки исполненин; 
при зтом приходитсн тратитћ соответствугогцие ресурсм (времени и памнти) на созда- 
ние, планирование и удаление потоков. Многае разработчики, обнаружив в программе 
простаивагогцие потоки, считагот, что дополнителћнме потоки уж точно будут делатг. 
что-нибудБ полезное. Однако при разработке масштабируемого и бБКтродеиствугогце- 
го приложенгш нужно старатћси избегатБ блокировки потоков, толбко в зтом случае 
их можно будет снова и снова исполвзоватБ длн решенгш других задач. В главе 27 mbi 
говорили о том, как потоки вбшолнигот вБшислителБНБГС операции, в то времи как 
глава 28 бвша посвигцена вБшолнениго потоками операции ввода-вБшода. 

ТеперБ пришло времн обсудитв вопросБ1 синхронизации потоков. Синхрони- 
зацин позволлет предотвратитв повреждение обгцих даннБгх при одновременном 
доступе к .')тим даннкш разнБ1х потоков. Слово <<одновременно» вБвделено не зри, 
ведБ синхронизацгш потоков целиком и полностбго базируетсл на контроле време- 
ни. Если доступ к неким даннвш со сторонБ1 двух потоков осугцествлнетси таким 
образом, что потоки никак не могут помешатв друг другу, синхронизации не тре- 
буетсн. В главе 28 6 бшо показано, как разнкгс секции асинхроннои функции могут 
вбшолннтбси разнБши потоками. Теоретически возможно, что два потока будут 
работатв с одними и теми же даннБши. Однако асинхроннБге функции реализованБ1 
таким образом, что два потока не будут одновременно работатв с одними данннши, 
позтому при обрагцении кода к данннш, содержагцимсн в асинхроннои функции, 
синхронизацгш потоков не нужна. 

Зтот случаи можно считатв идеалБНБш, так как синхронизацин потоков влечет 
за собои много проблем. Во-первБ1х, программироватБ код синхронизации краине 
утомителБно и при зтом легко допуститБ ошибку. В коде следует вБвделитБ все дан- 
нбгс, которБГС потенциалБно могут обрабатБшатБСи различнБши потоками в одно 
и то же времи. Затем все зти даннвге заклгочаготсн в другои код, обеспечивагогции 
их блокировку и разблокирование. Блокирование гарантирует, что доступ к ресурсу 
в каждвпг момент времени сможет получитв толбко один поток. Однако достаточно 
при программировании забв1ТБ заблокироватБ хотн 6 б1 один фрагмент кода, и ваши 
даннвге будут поврежденБт К тому же нет способа проверитБ, правилБно ли работает 
блокиругогции код. Остаетсн толбко запуститк приложение, провести многочислен- 
нбгс нагрузочнБге испБгтангш и надентБСн, что все проидет благополучно. При зтом 
тестирование желателвно осугцествлитБ на машине с максималБно возможнбш ко- 
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личеством процессоров, так как зто повмшает шансм вмпвитб ситуацшо, когда два 
и более потока попмтаготсл получитБ одновременнБШ доступ к ресурсу — а значит, 
повБШит шансБ1 на вБшвление проблемБк 

Второи проблемои блокированин ивллетсл снижение производителвности. 
Установление и сннтие блокировки требугот времени, так как длн зтого ввгоБшаготсн 
дополнителБНБге методБц причем процессорБ1 должнб1 координироватБ совместнуго 
работу, определлл, которвш из потоков нужно блокироватв первБш. Подобное 
взаимодеиствие процессоров не может не сказБшатвсл на производителБности. 
К примеру, рассмотрим код, добавлнгогции узел в начало свнзанного списка: 

// Зтот класс исполБзуетсл классом LinkedList 
public class Node { 
internal Node m_next; 

// ОсталБнме члени не показани 

} 

public sealed class LinkedList { 
private Node m_head; 

public void Add(Node newNode) { 

// Зти две строки реализуит бмстрое присваивание ссилок 
newNode.m_next = m_head; 
m_head = newNode; 

} 

} 

Метод Add просто оченв бр>1Стро присваивает ссбшки. И если mki хотим сделатБ 
вб130в зтого метода безопаснвш, дав возможностб разнБш потокам одновременно 
ББ 13 БшатБ его без риска повредитк свнзаннБпг список, следует добавитк к методу 
Add код установленгш и снитил блокировки: 

public sealed class LinkedList { 

private SomeKindOfLock m_lock = new SomeKindOfLock(); 
private Node m_head; 

public void Add(Node newNode) { 
m_lock.Acquire(); 

// Зти две строки вмполнлкрт бмстрое присваивание ссилок 
newNode.m_next = m_head; 
m_head = newNode; 
m_lock.Release(); 

} 

} 

Теперв метод Add стал безопаснБш в отношении потоков, но скороств его вбн 
полненгш серпезно упала. Снижение скорости работкг зависит от вида ввгбранного 
механизма блокировангш; сравнение производителвности различнБгх вариантов 
блокировангш делаетсл как в зтои, так и в следугогцеи главах. Но даже самое 6бг- 
строе блокирование заставлиет метод Add работатв в несколвко раз медленнее по 
сравнениго с его версиеи без блокировангш. И разумеетсн, вбгзов метода Add в цикле 
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длн вставки в свнзаннми список дополнитслбнмх узлов также значителБно снижает 
производителБностБ. 

ТретБн проблема состоит в том, что при блокировании в каждвш момент вре- 
мени допускаетсл доступ к ресурсам толбко одного потока. Собственно, дли зтого 
и 6 бшо придумано блокирование, но, к сожаленшо, подобное поведение приводит 
к созданшо дополиителБНБ1х потоков. То еств если поток пула пБмаетсл получитБ 
доступ к запертому ресурсу и не получает его, скорее всего, пул создаст eme один 
поток дли сохраненгш загрузки процессора. Как обсуждалосв в главе 26 , создание 
потока обходитсн краине дорого в смвгсле затрат памнти и сниженгш производи- 
телБности. Но хуже всего то, что после разблокировангш старвги поток понвлнетси 
в пуле вместе с новбгм; то естБ операционнои системе приходитсл планироватБ 
вБгполнение потоков, количество которвгх преввгшает количество процессоров, 
а значит, увеличиваетсл частота переклгочении контекста, что, опнтб же, отрица- 
телБно сказБгваетсн на производителвности. 

Словом, синхронизации потоков имеет столбко нежелателБнкгх последствии, 
что приложенгш следует проектироватв так, чтобкг она применнласБ как можно 
реже. Избегаите обгцих даннкгх — например, статических полеи. Когда поток 
конструирует новбги обвект оператором new, оператор возврагцает ссвглку на зтот 
обвект. Причем в зтот момент ссвглка имеетси толбко у создагогцего обвект потока, 
длн других потоков он недоступен. Если не передаватв зту ссбглку другому потоку, 
которнги может исполБЗОватБ обвект одновременно с потоком, создавшим обвект, 
необходимоств в синхронизации отпадает. 

Стараитесв по возможности работатв со значимБгми типами, потому что они 
всегда копируготсл, и каждвги поток в итоге работает с собственнои копггеи. Ну и, 
наконец, нет нггчего страшного в одновременном доступе разнвгх потоков к обгцггм 
даннвгм, еслгг зти даннБге предназначенБг толбко длн чтенггн. К прггмеру, многгге пргг- 
ложенгш в процессе инггцггалггзацгггг создагот структурвг даннвгх. После ггнггцггалгг- 
зации приложенгге может создатн столбко потоков, сколбко считает необходимкгм; 
и еслгг все зти потокгг решат получитв доступ к зтим даннкгм, онгг смогут сделатн зто 
одновременно, не прибегаи нгг к блокггрованггго, нгг к разблокггрованггго. Примером 
такого поведенгш служит тип Stning. Созданнвге строкгг неизменнБг, позтому одно- 
временнБги доступ к нгтм можно предоставитБ произволБному количеству потоков, 
не опасаисБ повреждентш даннвгх. 


Библиотеки классов и безопасностБ потоков 

А сеичас хотелосБ 6бт сказатБ несколБКО слов о библиотеках классов и сгтнхронгг- 
зацгггг потоков. Бттблттотека FCL разработкгг Microsoft гарантттрует безопасноств 
в отношенгггг потоков всех статическттх методов. Зто означает, что одновременнБш 
вбгзов статического метода двуми потоками не прггводит к поврежденттто даннвгх. 
Механггзм загцитБг реалггзован внутри FCL, посколвку нет способа обеспечтттБ 
блокггровангте сборок различнвгх производителеи, споригцггх за доступ к ресурсу. 
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Класс Console содержит статическое поле, по которому многие из его методов 
устанавливагот и снимагот блокировку, гарантирун, что в каждми момент времени 
доступ к консоли будет толгжо у одного потока. 

Кстати, создание метода, безопасного в отношении потоков, не означает, что 
внутренне он реализует блокирование в рамках синхронизации потоков. Просто зтот 
метод предотврагцает повреждение даннмх при попмтке одновременного доступа 
к ним со сторонм несколБКих потоков. Класс System.Math обладает статическим 
методом Мах, которми реализован следугогцим образом: 

public static Int32 Max(Int32 vall, Int32 val2) { 
return (vall < val2) ? val2 : vall; 

} 

Зтот метод безопасен в отношении потоков, хотн в нем нет никакого кода бло- 
кированин. Так как тип Int 32 относитсл к значиммм, два значенгга зтого типа при 
передаче в переменнуго Мах копируготсл, а значит, разнме потоки могут одновре- 
менно обрагцатБСи к даннои переменнои. При зтом каждћш поток будет работатк 
с собственнБгми даннБгми, изолированнБши от всех прочих потоков. 

В то же времл FCL не гарантирует безопасности в отношении потоков зкзем- 
плирнБш методам, так как введение в них блокиругогцего кода слишком силбно 
сказБшаетсн на производителБности. Более того, если кажднш зкземплнрнБпг метод 
начнет вбшолннтб блокирование и разблокирование, все закончитсн тем, что в при- 
ложенгш в каждвш момент времени будет исполнитбсн толбко один поток, что егце 
болБше снизит производителБностБ. Как уже упоминалосБ, поток, конструиругогцгш 
обвект, ивлнетсл единственнвш, кто имеет к нему доступ. Другим потокам даннкш 
oo'bcin недоступен, а значит, при вБгзове зкземплнрнвгх методов синхронизацгга не 
трсбустсм. Однако если потом поток предоставит ссвшку на обвект (поместив ее 
в статическое поле, передав ее в качестве аргумента состоннгга методу ThreadPool . 
QueueUserWorkItem или обвекту Task и т. п.), то тут синхронизацгга уже понадо- 
битсл, если разнвге потоки попБгтаготсл одновременно получитв доступ к даннкш 
не толбко длл чтенгга. 

СобственнБге библиотеки классов рекомендуетсл строитв по зтому паттер- 
ну — то естБ все статические методвг следует сделатв безопаснвши в отношенгш 
потоков, а зкземплнрнБге методБг — нет. Впрочем, следует оговоритБ, что если це- 
лбго зкземплирного метода лвлнетси координирование потоков, его тоже следует 
сделатв безопаснБш в отношенгш потоков. К примеру, один поток может отменнтв 
операциго, вБгзБгваи метод Cancel класса CancellationTokenSource, а другои по- 
ток, деланзапросксоответствугогцему своиству IsCancellationRequested обвекта 
CancellationToken, может обнаружитв, что отмена на самом деле не нужна. Внутри 
зтих зкземплнрнБгх методов содержитсл специалвнБШ код синхронизацгш потоков, 
гарантиругогцгш их скоординированнуго работу 1 . 


1 Поле, к которому осугцествллгот доступ оба члена, помечаетсл клгочевнм словом volatile, 
О котором Mbl поговорим чутв позже. 
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Примитивнме конструкции 
полБЗОвателвского режима 
и режима лдра 

В зтои главе рассматриваготси примитивнме конструкции длл синхронизации по- 
токов. Под <<примитивнмми» н подразумеваго простеишие конструкции, которме 
доступнм в коде. Они бмвагот двух видов: полБЗОвателБСКого режима и режима ндра. 
По возможности нужно задеиствоватв первБ1е, так как они значителБно бн1стрее 
вторБ1х и исполБзугот дли координации потоков специалБНБШ директивБ1 процес- 
сора. То естБ координацгш имеет место уже на аппаратном уровне (и именно зто 
обеспечивает бБКтродеиствие). Однако одновременно зто означает, что блокировка 
потоков на уровне примитивнои конструкции полвзователБСКого режима опера- 
ционнои системои Windows просто не распознаетси. А так как заблокированнБш 
таким способом поток пула не считаетси таковнш, пул не создает дополнителБНБ1х 
потоков длн восполненин загрузки процессора. Кроме того, блокировка происходит 
на оченв короткое времл. 

Звучит заманчиво, не правда ли? Более того, все деиствителвно так, именно 
позтому 'А рекомендуго исполБЗОватк зти конструкции как можно чагце. Впрочем, 
они не идеалБНБт Толбко лдро операционнои системБ1 Windows может остановитБ 
вБшолнение потока, что 6 б 1 он перестал впустуго расходоватв ресурсБ1 процессора. 
ЗапугценнБш в полвзователБСКом режиме поток может 6 б 1 тб прерван операционнои 
системои, но доволбно бБ1Стро снова будет готов к работе. В итоге поток, которвш 
пБ1таетсл, но не может получитн некоторБпг ресурс, начинает циклически сугцество- 
ватБ в полвзователБСКом режиме. Потенциалкно зто нвлнетсл пуствш расходованием 
времени процессора, которое лучше 6 бшо 6 бг потратитБ с полбзои — или просто 
разрешитБ процессору простаиватБ длл зкономии знергии. 

Зто заставллет нас переити к примитивнвш конструкцгшм режима ндра. Они 
предоставлиготсл самои операционнои системои Windows и требугот от потоков 
приложенгш вБгзова функции, реализованнвгх в идре. Переход потока между полб- 
зователБСКим режимом и режимом лдра требует значителкнБгх затрат ресурсов, 
позтому конструкции режима идра краине желателвно избегатБ 1 . Однако и у них 
естБ свои достоинства. Если один поток исполБзует конструкциго режима ндра длн 
полученгш доступа к ресурсу, с которкш уже работает другои поток, Windows бло- 
кирует его, что6бг не тратитБ понапрасну времи процессора. А затем, когда ресурс 
становитсл доступнвш, блокировка снимаетсл, и поток получает доступ к ресурсу. 

Если поток, исполБзугогции в даннБги момент конструкциго, не освободит ее, 
ожидагогции конструкции поток может оказатвсн заблокированнБш навсегда. В зтом 
случае в полвзователБСКом режиме поток бесконечно исполниетси процессором; 
зтот вариант блокировки назБгваетсл активноп (живоп) блокировкоп (livelock), 


i 


ЧутБ далБше в зтои главе показана программа, измерпготцал производителБностБ. 
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или зависанием. В режиме лдра поток блокируетсл навсегда, зтот тип блокировки 
назБшаетсл взаимноп (.мертвоп) блокировкоп (deadlock). Обе ситуации по-своему 
плохи, но если вБ1биратБ из двух зол, второи вариант видитсл более предпочти- 
телвнБш, потому что в первом случае впустуго расходуготсп как времл процессора, 
так и памнтв (стек потока и т. п.), а во втором случае расходуетсл толбко памнтБ 1 . 

В идеалБном мире у нас бпши 6бг конструкции, сочетагогцие лучшие особенности 
обоих типов: бвгстро работагогцие и не блокиругогциесн (как конструкции полвзова- 
телвского режима) в условгшх отсутствгш конкуренции. А если конструкции начи- 
нали 6бг соперничатБ друг другом, их блокировало 6бг ндро операционнои системБг. 
ОписаннБге конструкцгш даже сугцествугот в природе, н назвшаго их гибридними 
(hybrid constructs), и мбг рассмотрим их в следугогцеи главе. Именно гибриднБге 
конструкции обкгчно исполБзуготсл в приложешшх, так как в болБшинстве прило- 
жении несколБКО потоков краине редко пвгтаготсл одновременно получитв доступ 
к одним и тем же даннкш. ГибриднБге конструкции основное времл поддерживагот 
бвгструго работу приложенгш и периодически замедллготсн, блокирун поток. Одна- 
ко зто замедление в тот момент не имеет особого значенгш, потому что поток все 
равно будет заблокирован. 

Многие ггз конструкции синхронизации потоков в CLR нвлнготсн всего лишб о6б- 
ектно-ориентированнБши оболочками классов, построеннвгх на базе конструкции 
синхронизации потоков Win32. В конце концов, CLR -потоки нвлнготсл потоками 
операционнои системвг Windows, котораи планирует и контролирует их синхро- 
низациго. Конструкции синхронизации сугцествугот с 1992 года и о них написано 
множество книг 2 , позтому в зтои главе м ограничусБ лишб кратким обзором. 


Конструкции полБЗОвателБСкого режима 

CLR гарантирует атомарностн чтенгш и записи следугогцих типов даннвгх: Boolean, 
Chan, (S)Byte, (U)Intl6, (U)Int32, (U)IntPtn, Single и ссбглочнбгх типов. Зто озна- 
чает, что все баитвг переменнои читаготси или записБшаготси одновременно. Пред- 
положим, имеетсн следугогции класс: 

internal static class SomeType { 
public static Int32 х = 0; 

} 

Если какои-то поток ввшолннет следугогцуго строку кода, то переменнаи х сразу 
(атомарно) изменнетсл с 0x00000000 до 0x01234567: 

SomeType.x = 0x01234567; 


1 Л считаго, что вБвделеннан потоку памнтв расходуетсл впустуго, если поток не вмполннет 
никакои полезнои работБГ. 

2 В моеи книге <<Windows via С/С++» (Microsoft Press, 2007) зтои теме посвншено не- 


сколбко глав. 
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При зтом посторонние потоки не увиднт переменнукз в промежуточном состо- 
лнии. К примеру, другои поток не может запроситБ своиство SomeType . х и полу- 
читб значение 0x01230000. Предположим, что поле х класса SomeType относитсл 
к типу Int64. Если поток вБшолнит следукдцук) строку кода, то другои поток смо- 
жет сделатБ запрос переменнои х и получитБ значение 0x0123456700000000 или 
0x0000000089abcdef , так как операции чтенин и записи не лвлпготси атомарнвши: 

SomeType.x = 0x0123456789abcdef ; 

Зто пример так назБшаемого прерванного чтенил (torn read). 

Хотл атомарнБ1и доступ к переменнои гарантирует, что чтение и записк осу- 
гцествлнкзтсн одновременно, из-за работБ1 компилнтора и оптимизации процессора 
вб1 не можете знатБ, когда именно произоидет чтение или записБ. ПримитивнБ1е 
конструкции полБЗОвателБСКого режима, рассмотреннБге в зтом разделе, управлнгот 
временем вБшолненгш зтих атомарнБгх операции. Кроме того, они обеспечивагот 
атомарноств и управление временем ввшолнешш длл переменнБгх типов даннвгх 
U(Int64) и Double. 

ПримитивнБге конструкции синхронизации потоков полвзователБСКого режима 
деллтсл на два типа: 

□ Volatile -конструкции вбшолннгот длн переменнои, содержагцеи даннБге простого 
типа, атомарнуго операциго чтенгш или записи. 

□ Interlocked -конструкции вбшолннгот дли переменнои, содержагцеи даннБге про- 
стого типа, атомарнуго операциго чтенгш и записи. 

Конструкции обоих типов требугот передачи ссбглки (адреса в памнти) на пере- 
меннуго, принадлежагцуго к простому типу даннвгх. 


Volatile -конструкции 

Когда компБготерБг толбко понвилисб, программное обеспечение писалосБ на ассем- 
блере. Зто 6бшо краине утомителкное занптие, так как программист должен 6бш 
формулироватБ все в нвном виде: исполвзоватБ определеннБпг регистр процессора, 
передатБ управление, осугцествитБ косвеннБпг вбгзов и т. п. Длн упрогценгш задачи 
6бши придуманБг лзбгки ВБ 1 СОКОГО уровнн. Именно в них вперввге 6бши реализованБг 
привБгчнБге конструкции if/else, switch/case, циклбг, локалБИБге переменнБге, 
аргументБг, вбгзовбг виртуалБНБгх методов, перегрузка операторов и многое другое. 
В конечном итоге компшштор преобразует конструкции вбгсокого уровнн в низ- 
коуровневвге, позволигогцие компвготеру поннтб, что именно ему следует делатБ. 

Другими словами, компгшнтор C# преобразует конструкции извгка C# в коман- 
дбг промежуточного ri:ii)i ка (Intermediate Language, IL), которнге, в свого очередв, 
JIT -компилнтор преврагцает в машиннБге директивБг, обрабатБшаемБге уже непо- 
средственно процессором. При зтом компшштор С#, JIT -компгшитор и даже сам 
процессор могут оптимизироватв ваш код. К примеру, после компгшнции следуго- 
гции нелепБпг метод в конечном итоге превратитсл в ничто: 
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private static void OptimizedAway() { 

// Вђ 1 численнал во времл компиллции константа равна нулк) 

Int32 value = (1 * 100) - (50 * 2); 

// Если значение равно 8, цикл не внполнлетсл 
for (Int32 х = 0; х < value; х++) { 

// Код цикла не нужно компилироватБЈ так как он никогда не внполнлетсл 
Console.WriteLine("Deff"); 

} 

} 


В зтом коде компилнтор вмнсннет, что значение всегда равно 0 , а значит, цикл 
никогда не будет вмполнен и соответственно нет никакои нуждм компилироватБ код 
внутри него. От метода в итоге может ничего не остатБСн. Далее, при компилиции 
метода, вБгзБшаклцего метод OptimizedAway, JIT -компшштор попБгтаетси встроитБ 
туда код метода OptimizedAway, но так как зтот код отсутствует, компилитор даже 
исклгочит сам код ввгзова метода. Разработчики оченв лгобнт зто своиство компи- 
литоров. Обвгано код пкгтаготсн писатБ максималБно осмБгсленно; он должен 6бгтб 
простБ1м длл чтенин, записи и редактированин. А затем компилитор переводит 
его на ИЗБ1К, понитнбш компБГОтеру. И мбг хотим, что6бг компилиторБ1 делали зто 
максималБно хорошо. 

В процессе оптимизации кода компилитором С#, JIT -компилитором и про- 
цессором гарантируетсл сохранение его назначенгш. То естк с точки зренгш одного 
потока метод делает то, зачем мбг его написали, хотл способ реализации может от- 
личатБСи от описанного в исходном коде. Однако при переходе к многопоточнои 
конфигурации ситуацгш может изменитвсл. Вот пример, в котором в резулвтате 
оптимизации программа стала работатн не так, как ожидалосБ: 

internal static class StrangeBehavior { 

// Далее Bbi увидите, что проблема решаетсл обБЛВлением зтого полл volatile 

private static Boolean s_stopWorker = false; 

public static void Main() { 

Console.WriteLine("Main: letting worker run for 5 seconds"); 

Thread t = new Thread(Worker); 

t.Start(); 

Thread.Sleep(5000); 

s_stopWorker = true; 

Console.WriteLine("Main: waiting for worker to stop"); 

t.Doin(); 

} 

private static void Worker(Object o) { 

Int32 х = 0; 

while (!s_stopWorker) x++; 

Console.WriteLine("Worker: stopped when x={0}", х); 

} 

} 
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Метод Main в зтом фрагменте кода создает новми поток, исполннкнции метод 
Worken, которми считает по возрастагогцеи, пока не получит команду остановитБСн. 
Метод Main позволиет потоку метода Worker работатБ 5 секунд, а затем останав- 
ливает его, присваиван статическому полго Boolean значение true. В зтот момент 
поток метода Worker должен ввшести резулитат счета, после чего он завершитси. 
Метод Main ждет завершенгш метода Worker, ввшБшает метод Doin, после чего по- 
ток метода Main возврагцает управление, заставлин весв процесс прекратити работу. 

Вбшллдит просто, не так ли? Но программа скркшает потенциалБНБге проблемБ1 
из-за возможнБ 1 х оптимизации. При компилнции метода Worker компилнтор обна- 
руживает, что переменнаи s_stopWorker может приниматБ значение true или f alse, 
но внутри метода зто значение никогда не меннетсл. Позтому компилитор может 
создатв код, заранее провернгогции состонние переменнои s_stopWorker. Если она 
имеет значение true, вбшодитсл резулитат "Worker: stopped when х=0". В про- 
тивном случае компшштор создает код, входнгции в бесконечнвш цикл и бесконечно 
увеличивагогции значение переменнои х. При зтом оптимизацгш заставллет цикл 
работатв краине бкгстро, так как проверка переменнои s_stopWorker осугцествлнетсн 
перед циклом, а проверки переменнои на каждои итерации цикла не происходит. 

Если вб1 хотите посмотретБ, как зто работает, поместите код в фаил с расширени- 
ем .cs и скомпилируите его с клгочами platform : х86 и /optimize+ компилнтора С#. 
Запустите полученнБш исполниемБпг фаил и вбг убедитесБ, что программа работает 
бесконечно. Обратите внимание, что вам нужен JIT -компилитор длл платформвг 
х86, которБпг совершеннее компшшторов х64 и IA64, а значит, обеспечивает более 
полнуго оптимизациго. ОсталБнвге Ј1Т-компилнторБ1 не вбшоличгот оптимизациго 
столб тгцателБно, позтому после их работиг программа успешно завершитси. Зто 
подчеркивает егце один интереснБпг аспект: итоговое поведение вашеи программвг 
зависит от множества факторов, в частности от вБгбраннои версии компилнтора и ис- 
полвзуемБгх клгочеи, от вБгбранного JIT -компилнтора, от процессора, которБпг будет 
вбшолннтб код. Кроме того, программа не станет работатк бесконечно, если запуститБ 
ее в отладчике, так как отладчик заставлнет JIT -компилнтор ограничитБСн неопти- 
мизированнБш кодом, которкпг прогце поддаетси вБшолнениго в пошаговом режиме. 

Рассмотрим другои пример, в котором пара потоков осугцествллет доступ к двум 
полим: 

internal sealed class ThreadsSharingData { 
private Int32 m_flag = 0 ; 
private Int32 m_value = 0 ; 

// Зтот метод исполнпетсп одним потоком 
public void Threadl() { 

// ПРИМЕЧАНИЕ. Они могут виполндтБсл в обратном порпдке 
m_value = 5; 
m_flag = 1; 

} 


// Зтот метод исполнлетсл другим потоком 
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public void Thread2() { 

// ПРИМЕЧАНИЕ. Поле m_value может 6biTb прочитано ранћше, чем m_flag 
if (m_flag == 1) 

Console.WriteLine(m_value); 

} 

} 

B данном случае проблема в том, что компилнторм и процессор могут оттрансли- 
роватБ код таким образом, что две строки в методе Threadl помениготсн местами. 
Разумеетсн, зто не изменит предназначении метода. Метод должен получитБ зна- 
чение 5 в переменнои m_value и значение 1 в переменнои m_f lag. С точки зрении 
однопоточного приложенгш порлдок вБшолненгш строк кода не имеет значенгш. 
Если же поменитБ указаннБге строки местами, другои поток, вбшолнигогции метод 
Thread2, может обнаружитн, что переменнан m_f lag имеет значение 1, и вБшедет 
значение 0. 

Рассмотрим зтот код с другои точки зренгш. Предположим, что код метода 
Threadl вБшолниетсл так, как предусмотрено программоп (то естн так, как он на- 
писан). ОбрабатБгван код метода Thread2, компшштор должен сгенерироватБ код, 
читагогции значенгш переменнкгх m_f lag и m_value из оперативнои памлти в ре- 
гистрвг процессора. И возможно, что памнтв первои ввгдаст значение переменнои 
m_value, равное 0. Затем может вбшолнитбси метод Threadl, меннгогции значение 
переменнои m_value на 5, а переменнои m_f lag — на 1. Но регистр процессора ме- 
тода Thread2 не видит, что значение переменнои m_value бвгло изменено другим 
потоком на 5. После зтого из оперативнои памлти в регистре процессора может 
6бгтб считано значение переменнои m_f lag, ставшее равнвгм 1. В резулБтате метод 
Thread2 снова ввгведет значение 0. 

Все зти краине непргштнБге со6бгтгш, скорее всего, приведут к проблемам в окон- 
чателБнои, а не в отладочнои версии программвг. В резулБтате задача вБшвленгш 
проблемвг и исправленгш кода становитсн нетривиалБнои. Позтому сеичас даваите 
поговорим о том, как исправитв код. 

Класс System . Threading . Volatile содержит два статических метода, которвге 
ВБ 1 ГЛИДИТ следугогцим образом 1 : 

public sealed class Volatile { 

public static void Write(ref Int32 locationj Int32 value); 
public static Int32 Read(ref Int32 location); 

} 

Зто специалБНБге методБг, отклгочагогцие оптимизации, обкгчно вБгполннемБге 
компиллтором С#, JIT -компилитором и собственио процессором. Вот как они 
работагот: 


1 Сугцествугот также перегруженнне версии методов VolatileRead и VolatileWrite, рабо- 
тагошие с типами: Boolean, (S)Byte, (U)Intl6, UInt32, (U)Int64, (U)IntPtr, Single, Double 
и T, где T — обобшеннви! тип с ограничением 'class' (ссшлочнше типш). 
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□ Метод Volatile .Wnite заставлнет записатБ значение в параметр location не- 
посредственно в момент обратценин. Более ранние загрузки и сохранении про- 
граммм должнм происходитБ до визова зтого метода. 

□ Метод Volatile . Read заставлиет считатБ значение параметра address непосред- 
ственно в момент обрагценин. Более поздние загрузки и сохраненин программвг 
должнб! происходитБ после вЂсзова зтого метода. 


ВНИМАНИЕ 

Что 6 б 1 не запутатБса, приведу простое правило: при взаимодеиствии потоков друг 
с другом через обидукз памлтБ записБ 1 ваите последнее значение методом Volatile. 
Write, а первое значение читаите методом Volatile.Read. 


ТеперБ при помогци указанннгх методов можно исправитв класс ThreadsShaning- 
Data: 

internal sealed class ThreadsSharingData { 
private Int32 m_flag = 0; 
private Int32 m_value = 0; 

// Зтот метод внполнлетсп одним потоком 
public void Threadl() { 

// ПРИМЕЧАНИЕ. 5 нужно записатБ в m_value до записи 1 в m_flag 
m_value = 5; 

Volatile.Write(ref m_flag, 1); 

} 

// Зтот метод внполнлетсд втормм потоком 
public void Thread2() { 

// ПРИМЕЧАНИЕ. Поле m_value должно 6biTb прочитано после m_flag 
if (Volatile.Read(ref m_flag) == 1) 

Console.WriteLine(m_value); 

} 

} 

Обрагцаго ваше внимание на четкое соблгодение правил. Метод Threadl записвг- 
вает два значенгш в полн, к которвш имегот доступ несколвко потоков. Последнее 
значение, которое мбг хотим записатБ (присвоение переменнои m_f lag значенгш 1), 
записБшаетсл методом Volatile . Write. Метод Thread2 читает обазначенгш из по- 
леи обгцего доступа, причем чтение первого из них (m_f lag) вБшолннетсл методом 
Volatile . Read. 

Но что здесБ происходит на самом деле? Длн метода Threadl вбгзов метода 
Volatile . Write гарантирует, что все записи в переменнвге будут завершенБг до за- 
писи значенин 1 в переменнуго m_f lag. Так как операцин m_value = 5 расположена 
до ввгзова метода Volatile .Write, она сначала должна завершитвси. Более того, 
значенгш сколбких 6бг переменнБгх ни редактировалисБ до вБгзова метода Volatile . 
Write, все зти операции следует завершитв до записи значениц 1 в переменнуго 
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m_f lag. При зтом все зти операции можно оптимизироватБ, вбшолннн их в лкзбом 
поридке; главное, что6бг все они закончилисв до вБгзова метода Volatile .Write. 

Вбгзов метода Volatile . Read длл метода Thread2 гарантирует, что значенгш 
всех переменнБгх будут прочитанБг после значенил переменнои m_f lag. Так как 
чтение переменнои m_value происходит после вБтзова метода Volatile . Read, оно 
должно осугцествлнтБСн толбко после чтенгш значенгш переменнои m_f lag. То же 
самое касастси чтенин всех осталвнБгх переменнБгх, расположеннБгх после внгзова 
метода Volatile . Read. При зтом операции чтенин после метода Volatile . Read 
можно оптимизироватБ, вбгполннн их в лгобом поридке; просто чтение станет не- 
возможнбгм до вБгзова метода Volatile . Read. 

Поддержка полеи Volatile в C# 

Как гарантироватБ, что программистБг будут корректно вбгзбгвдтб мстодбг Volatile . 
Read и Volatile . Write? Сложно продуматБ все, в частности представитБ, что 
именно могут делатн с обгцими даннБгми другие потоки в фоновом режиме. Длл 
упрогценин ситуации в C# бвгло введено клгочевое слово volatile, применнемое к 
статическим или зкземплирнБгм полнм типов Boolean, (S)Byte, (U)Intl6, (U)Int32, 
(U)IntPtr, Single и Char. Также оно применнетсл к ссбглочнбгм типам и лгобнгм 
перечислимБгм полим, если в основе последних лежит тип (S)Byte, (U)Intl6 или 
(U)Int32. JIT -компилитор гарантирует, что доступ к полим, помеченнвгм даннБгм 
клгочевБгм словом, будет происходитв в режиме волатилвного чтенин или записи, 
позтому в нвном виде вБгзвгватБ статические методкг Read и Write класса Volatile 
болБше не требуетсл. Более того, клгочевое слово volatile запрегцает компилито- 
ру C# и JIT -компшштору кзшироватБ содержимое поли в регистрвг процессора. 
Зто гарантирует, что при всех операцгшх чтенин и записи манипулнции будут 
производитБСл непосредственно с памнтвго. 

Клгочевое слово volatile позволиет переписатБ класс ThreadsSharingData 
следугогцим образом: 

internal sealed class ThreadsSharingData { 
private volatile Int32 m_flag = 0 ; 
private Int32 m_value = 0 ; 

// Зтот метод исполнпетсл одним потоком 
public void Threadl() { 

// ПРИМЕЧАНИЕ. Значение 5 должно 6biTb записано в m_value 
// перед записик) 1 в m_flag 
m_value = 5; 
m_flag = 1; 

} 

// Зтот метод исполннетсл другим потоком 
public void Thread2() { 

// ПРИМЕЧАНИЕ. Поле m_value должно бити прочитано после m_flag 
if (m_flag == 1) 

Console.WriteLine(m_value); 

} 

} 
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Некоторме разработчики (в том числе и) не лкзблт клгочевое слово volatile 
и считагот, что не стоило вводитб его в С# 1 . Mbi считаем, что болБшинству алго- 
ритмов не нужен одновременнБш доступ на чтение и записв поли со сторонБ 1 не- 
сколбких потоков. А в болБшинстве оставшихсн алгоритмов можно ограничитБСн 
обмчнмм доступом к полго, повмшагогцему производителБностБ. А доступ к полго, 
помеченному как volatile, требуетсн краине редко. К примеру, сложно о6бнснитб, 
как применитБ операциго волатилБного чтенгш к такому вот алгоритму: 

m_amount = m_amount + m_amount; // Предполагаетсл, что поле m_amount 

// определено как volatile 

06бшно целое число может 6бггб удвоено простБш сдвигом всех битов на единицу 
влево, и многие компилиторБ1 могут обработатБ такои код и вбшолнитб указаннуго 
оптимизациго. Но если пометитБ поле m_amount клгочевБш словом volatile, оп- 
тимизацин станет невозможнои. Компиллтору придетсл создатБ код, читагогции 
переменнуго m_amount из регистра, затем читагогцгш ее егце раз из другого регистра, 
складБшагогцгш два значенгш и записБшагогцгш резулБтат обратно в поле m_amount. 
НеоптимизированнБпг код определенно занимает болБше места и медленнеи рабо- 
тает; врнд ли 6бшо 6bi уместно помегцатБ такои кода внутрБ цикла. 

К тому же C# не поддерживает передачу волатилБного поли по ссБшке в метод. 
К примеру, если принадлежагцее типу Int32 волатилБное поле m_amount попБгтаетсн 
ББгзватБ метод Int32 . Т ryParse, компилитор сгенерирует предупреждение: 

Boolean success = Int32.TryParse("123", out m_amount); 

// Зта строка приводит к сообценив от компилнтора: 

// CS0420: ссћшка на волатилвное поле не будет трактоватвсл как волатилвнал 

Наконец, полн volatile несовместимБ1 со спецификациеи CLS, потому что они 
не поддерживаготсн многими нзБгками (вклгочаи Visual Basic). 

Interlocked -конструкции 

Как мб1 вБшснгши, метод Read класса Volatile вБшолниет атомарнуго операциго 
чтенгш, а метод Write зтого же класса осугцествлнет атомарнуго операциго записи. То 
естБ каждБпг метод вБшолннет либо атомарное чтение, либо атомарнуго записБ. В зтом 
разделе мбг поговорим о статических методах класса System . Threading . Interlocked. 
КаждБш из зтих методов вБшолниет как атомарное чтение, так и атомарнуго записБ. 
Кроме того, все методБг класса Interlocked ставлт барБер в памлти, то естБ лгобаи 
записБ переменнои перед вбгзовом метода класса Interlocked вБшолннетсл до зтого 
метода, а все чтенгш переменнБгх после вБгзова метода вбшолннготсл после него. 

Статические методБц работагогцие с переменнБши типа Int32, безоговорочно 
относлтсл к наиболее часто исполБзуемБш. Продемонстрируем их: 

public static class Interlocked { 

// Вовврацает (++location) 


l 


Кстати, Microsoft Visual Basic не содержит встроеннои семантики volatile. 
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public static Int32 Increment(ref Int32 location); 

// Возврацает (--location) 

public static Int32 Decrement(ref Int32 location); 

// Возврацает (location += value) 

// ПРИМЕЧАНИЕ. Значение может 6biTb отрицателвннм, 

// что позволвет вмполнитц вћ 1 читание 

public static Int32 Add(ref Int32 location, Int32 value); 

// Int32 old = location; location = value; возврацает old; 
public static Int32 Exchange(ref Int32 location, Int32 value); 

// Int32 old = locationl; 

// если (locationl == comparand) location = value; 

// возврацает old; 

public static Int32 CompareExchange(ref Int32 location, 

Int32 value, Int32 comparand); 

} 

Сушествугот и перегруженнме версии зтих методов, работагогцие со значени- 
нми типа Int64. Кроме того, в классе Interlocked сугцествугот методм Exchange 
и CompareExchange, принимакнцие параметрм Object, IntPtr, Single и Double. 
Естб и обобгценнан версин, в которои обобгценнми тип ограничен типом class 
(лгобои ссмлочнми тип). 

Лично мне оченв нравитсл Interlocked -методм, потому что они работагот 
относителБно бмстро и позволнгот многого добитБСл. Даваите рассмотрим код, 
исполБзугогции даннме методм длл асинхронного запроса даннмх с различнмх 
веб-серверов. Зто короткии код, не блокиругогции никаких потоков, автоматическгг 
маспгтабируемми с исполБЗОванием потоков пула и исполБзугогции все доступнме 
процессорм, если их загрузка может поити ему на полБзу. Кроме того, количе- 
ство серверов, на которме код в исходном виде поддерживает доступ, достигает 
2 147 483 647 (Int32 .MaxValue). Другими словами, зто превосходнаи основа дли 
написангга собственнмх сценариев. 

internal sealed class MultiWebRequests { 

// Зтот класс Helper координирует все асинхроннме операции 
private AsyncCoordinator m_ac = new AsyncCoordinator(); 

// Набор веб-серверов, к котормм будут посмлатцсл запроси 
// Хотл к зтому словарш возможнм одновременние обраценил, 

// в синхронизации доступа нет необходимости, потому что 
// клкјчи после созданил доступнм толцко длл чтенил 

private Dictionary<String, Object> m_servers = new Dictionary<String, Object> { 

{ "http://Wintellect.com/", null }, 

{ "http://Microsoft.com/", null }, 

{ "http: //1 .1.1. 1/", null } 

}; 


public MultiWebRequests(Int32 timeout = Timeout.Infinite) { 
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// Асинхронное инициирование всех запросов 
var httpClient = new HttpClient(); 
foreach (var server in m_servers.Keys) { 
m_ac.AboutToBegin(l); 
httpClient.GetByteArrayAsync(server) 

.ContinueWith(task => ComputeResult(server, task)); 

} 

// Сообцаем AsyncCoordinator, что все операции бмли инициированн 
// и что он должен вћвватц AllDone после завершенил всех операции, 
// вшзова Cancel или таим-аута 
m_ac . AllBegun(AllDone, timeout); 


private void ComputeResult(String server, Task<Byte[]> task) { 

Object result; 

if (task.Exception != null) { 

result = task.Exception.InnerException; 

} else { 

// Обработка завершенив ввода-вшвода - здесц или в потоке(-ах) пула 
// Разместите свои вшчислителцнми алгоритм... 
result = task.Result . Length; // B данном примере 
} // просто возврашаетсл длина 

// Сохранение резулцтата (исклгачение/сумма) 

// и обозначение однои завершеннои операции 
m_servers[server] = result; 
m_ac . DustEnded(); 


// При BbBOBe зтого метода резулцтатш игнорируттсл 
public void Cancel() { m_ac.Cancel(); } 

// Зтот метод вћ 1 знваетсл после полученил ответа от всех веб-серверов, 

// вшзова Cancel или таим-аута 

private void AllDone(CoordinationStatus status) { 
switch (status) { 

case CoordinationStatus.Cancel: 

Console.WriteLine("Operation canceled."); 
break; 

case CoordinationStatus.Timeout: 

Console.WriteLine("Operation timedout."); 
break; 

case CoordinationStatus.AllDone: 

Console.WriteLine("Operation completed; results below:"); 
foreach (var server in m_servers) { 

Console.Write("{0} ", server.Key); 

Object result = server.Value; 
if (result is Exception) { 

Console.WriteLine("failed due to {0}.", result.GetType().Name) 
} else { 
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Console.Writel_ine("returned {0:N@} bytes.", result); 

} 

} 

break; 

} 

} 

} 

Зтот код непосредственно не задеиствует I n t е r 1 о с l< е d - м с т о/ 1 , р> i , так как весБ ко- 
ординируговдии код инкапсулирован в класс AsyncCoordinator. Н подробнее опишу 
его ниже, а пока расскажу, что зтот класс делает. В процессе конструированин класс 
MultiWebRequest инициализирует класс AsyncCoordinator и словарБ с набором 
URI серверов (и их будувдих резулћтатов). Затем он асинхронно ввшолннет все 
веб-запросБ 1 . Сначала вБВДБшаетси метод AboutToBegin класса AsyncCoordinator, 
которому передаетсл количество запланированнБ 1 Х запросов 1 . Затем происходит 
инициирование запроса вбгоовом метода GetByteArrayAsync класса HttpClient. 
Метод возвравдает обвект Task, длн которого м вввдБшаго ContinueWith, что 6 б 1 при 
полЈвдении ответа сервера полученнвге баитБ1 параллелБно обрабатБшалисБ методом 
ComputeResult во многих потоках пула. После завершенгш всех запросов к веб- 
серверам вБкзБшаетсн метод AllBegun класса AsyncCoordinator, которому передаетсл 
имн метода, которкш следует запуститБ после вБшолненин всех операции (AllDone), 
а во-вторБ 1 х, продолжителБностБ таим-аута. После ответа каждого сервера различнвге 
потоки пула будут вввдБшатБ метод ComputeResult класса MultiWebRequests. Зтот 
метод обрабатБшает баитБц возвравденнБге сервером (или лгобвге ошибки), и сохра- 
ниет резулвтат в словаре. После сохраненгш каждого резулвтата вБ13Бшаетсл метод 
DustEnded класса AsyncCoordinator, позволнговдии обвекту AsyncCoordinator 
узнатв о завершении операции. 

После завершенгш всех операции обвект AsyncCoordinator вввдБшает метод 
AllDone дли обработки резулктатов, полученнБ 1 х со всех веб-серверов. Зтот метод 
будет вБшолннтБСн потоком пула, последним получившим ответ с сервера. В случае 
завершенгш времени ожиданин или отменБ 1 операции метод AllDone будет вБ13ван 
либо потоком пула, уведомлиговдим обвект AsyncCoordinator о том, что времн 
закончилосБ, либо потоком, вБШвавшим метод Cancel. Сувдествует также веронт- 
ностб, что поток, вбшолннговдии запрос к серверу, сам вввдовет метод AllDone, если 
последнии запрос завершитси до вввдова метода AllBegin. 

Имеите в виду, что в данном случае имеет место ситуацин гонки, так как воз- 
можно одновременное завершение всех запросов к серверам, вбгоов метода AllBegun, 
завершение времени ожидашш и вбгоов метода Cancel. Если такое произоидет, о 6 б- 
ект AsyncCoordinator вБ 1 берет победителл, гарантирул, что метод AllDone будет 
вБ13ван не более одного раза. Победителв указБшаетсл передачеи в метод AllDone 
аргумента состолнгш, ролв которого может игратк одно из символических имен, 
определеннБ 1 х в типе CoordinationStatus: 
internal enum CoordinationStatus { AllDone, Timeout, Cancel }; 


1 Код будет работатБ корректно, даже если ВБИватБ метод m_ac. AboutToBeging(m_requests. 
Length) всего один раз перед циклом вместо ввмова метода AboutToBegin внутри цикла. 
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Tenepb, когда вм получили представление о том, что происходит, посмотрим, 
как зто работает. Класс AsyncCoordinator содержит вск> логику координации по- 
токов. Во всех случалх он испо./њзуст методм Interlocked, гарантирул бмстрое 
вмполнение кода и отсутствие блокировки потоков. Вот код зтого класса: 

internal sealed class AsyncCoordinator { 

private Int32 m_opCount = 1; // Уменвшаетсп на 1 методом AllBegun 

private Int32 m_statusReported = 0; II 0=falsej l=true 
private Action<CoordinationStatus> m_callback; 
private Timer m_timer; 

// Зтот метод ДОЛЖЕН 6biTb вмзван ДО инициированил операции 
public void AboutToBegin(Int32 opsToAdd = 1) { 

Interlocked.Add(ref m_opCount, opsToAdd); 

} 

// Зтот метод ДОЛЖЕН 6biTb вмзван ПОСЛЕ обработки резулитата 
public void 3ustEnded() { 

if (Interlocked.Decrement(ref m_opCount) == 0) 

ReportStatus(CoordinationStatus.AllDone); 

} 

// Зтот метод ДОЛЖЕН 6biTb вмзван ПОСЛЕ инициированин ВСЕХ операции 
public void AllBegun(Action<CoordinationStatus> callback, 

Int32 timeout = Timeout.Infinite) { 
m_callback = callback; 
if (timeout != Timeout.Infinite) 

m_timer = new Timer(TimeExpiredj null, timeout, Timeout.Infinite); 

3ustEnded(); 

} 

private void TimeExpired(Object o) { 

ReportStatus(CoordinationStatus.Timeout); 

} 

public void Cancel() { ReportStatus(CoordinationStatus.Cancel); } 

private void ReportStatus(CoordinationStatus status) { 

// Если состолние ни разу не передавалосц, передатц его; 

// в противном случае оно игнорируетсл 

if (Interlocked . Exchange(ref m_statusReported, 1) == 0) 

m_callback(status); 

} 

} 


Саммм важнмм в зтом классе нвлнетсл поле m_opCount. В нем отслеживаетсн 
количество асинхроннмх операции, ожидакзгцих вмполненин. Перед началом каждои 
такои операции вмзмваетсл метод AboutToBegin. Он вмзмвает метод Interlocked . 
Add, чтобм атомарно добавитБ к полвз m_opCount переданное в него число. Операцин 
суммировангш должна осугцествлнтмш атомарно, так как веб-серверм могут отвечатБ 
потокам пула в процессе начала дополнителБнмх операции. При каждом ответе 



Конструкции полнзователиского режима 837 


сервера вмзмваетсн метод DustEnded. Он вмзмвает метод Interlocked . Decrement 
и атомарно вмчитает из переменнои m_opCount единицу. Поток, присвоившии пере- 
меннои m_opCount значение 0, вмзмвает метод ReportStatus. 

ПРИМЕЧАНИЕ 

Полкз m opCount присваиваетсл началиное значение 1 (не 0); зто краине важно, так 
как гарантирует, что метод AIIDone не будет вмзван во времл запроса к серверу по- 
током, исполнл 101 цим метод конструктора. До вмзова конструктором метода AIIBegun 
переменнал m opCount не может получитв значение 0. Вмзваннми же конструктором 
методАНВедип, в свокз очередв, Bbi3biBaeTMeTOflJustEnded, которми последователвно 
уменишает значение переменнои m opCount на 1 и фактически отменлет зффект 
присвоенил еи началиного значенил 1. В резулвгате переменнал m opCount может 
достичи значенил 0, но толико после того как мм получим информацикз об отправке 
всех запросов к веб-серверам. 


Метод ReportStatus вмполннет функциго арбитра в гонке, котораи может воз- 
никнутБ между завершагогцимисн операцинми, истечением времени ожиданин 
и вмзовом метода Cancel. Он должен убедитБСн, что толбко одно из условии рас- 
сматриваетсл в качестве победителн, и метод m_callback будет вБгзван всего один 
раз. Арбитраж осушествлнетсн передачеи методу Interlocked . Exchange ссбшки на 
поле m_statusReported. Зто поле рассматриваетсл как переменнаи типа Boolean; 
но на самом делеподобное невозможно, так как методћг класса Interlocked непри- 
нимагот переменнБгх типа Boolean. Позтому мбг исполБзуем переменнуго типа Int32, 
значение 0 которои нвлнетсн зквивалентом f alse, а значение 1 — зквивалентом true. 

Внутри метода ReportStatus вбгзов метода Interlocked . Exchange мениет 
значение переменнои m_statusReported на 1. Но толбко первБш проделавшии зто 
поток увидит, как метод Interlocked. Exchange возврагцает значение 0, и толбко 
он активизирует метод обратного ввгзова. Все осталвнвге потоки, вБгзвавшие метод 
Interlocked . Exchange, получат значение 1, по сути, уведомлнгогцее их, что метод 
обратного ввгзова уже активизирован и болвше зтого делатБ не нужно. 

Реализацил простои циклическои блокировки 

Interlocked -методБг прекрасно работагот, но в основном со значенинми типа Int32. 
А что делатв, если возникла необходимоств атомарного манипулировангш набором 
полеи обвекта? Нам потребуетсн предотвратитв проникновение всех потоков кроме 
одного в областв кода, управлнгогцуго полими. Interlocked -методБг позволнгот вбг- 
полнитб блокирование в рамках синхронизации потоков: 

internal struct SimpleSpinLock { 

private Int32 m_ResourceInUsej // 0=false (по умолчаник)), l=true 

public void Enter() { 
while (true) { 

// Всегда указмватБ, что ресурс исполБзуетсл. 
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// Если поток переводит его из свободного состонниВј 
// вернути управление 

if (Interlocked . Exchange(ref m_ResourceInUsej 1) == 0) return; 

// Здеси что-то происходит. .. 

} 

} 

public void Leave() { 

// Помечаем ресурс, как свободнми 
Volatile.Write(ref m_ResourceInUse, 0); 

} 

} 

А вот класс, демонстрируклции исполБЗОвание метода SimpleSpinLock: 

public sealed class SomeResource { 

private SimpleSpinLock m_sl = new SimpleSpinLock(); 

public void AccessResource() { 
m_sl.Enter(); 

// Доступ к ресурсу в каждни момент времени имеет толико один поток... 
m_sl.Leave(); 

} 

} 

Реализацин метода SimpleSpinLock оченБ проста. Если двапотокаодновременно 
вмзБшагот метод Enter, метод Interlocked . Exchange гарантирует, что один поток 
изменит значение переменнои m_resourceInUse с 0 на 1. Когда он видит, что пере- 
меннан m_resourceInUse равна 0, он заставлнет метод Enter возвратитБ управление, 
что 6 б 1 продолжитБ вБшолнение кода метода AccessResource. Второи поток тоже 
попБггаетсл заменитБ значение переменнои m_resourceInUse на 1. Но зтот поток 
увидит, что переменнаи уже не равна 0, и зациклитсл, начав непрервшно ввгоБшатБ 
метод Exchange до тех пор, пока первБш поток не вБИОвет метод Leave. 

После того как перввш поток завершит манипулиции полими обвекта 
SomeResource, он ввгзовет метод Leave, которвш, в свого очередв, вБИОвет метод 
Volatile .Write и вернет переменнои m_resourceInUse значение 0. Зто заставит 
зациклившииси поток поменитв значение переменнои m_resourceInUse с 0 на 1 и, 
наконец, получитк управление от метода Enter, предоставлин последнему доступ 
к поллм обвекта SomeResource. 

Вот и все. Зто оченв простан реализацгш блокированин в рамках синхронизации 
потоков. Правда, ее сервезнвш потенциалвнБш недостаток состоит в том, что при 
наличии конкуренции за право на блокирование потоки ввшужденБ1 ожидатБ блоки- 
рованин в цикле, и зто зацикливание приводит к пустому расходованиго бесценного 
процессорного времени. Соответственно, блокирование с зацикливанием имеет 
СМБ1СЛ исполБЗОватБ толбко длн загцитБ1 очснб бБгстро вБшолннемБгх областеи кода. 

Блокирование с зацикливанием обвгчно не применчетсн на машинах с одним 
процессором, так как зацикливание другого потока-претендента помешает бвг- 
строму сннтиго блокировки. Ситуацгш осложннетсл, если поток, удерживагогции 
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блокировку, имеет более низкии приоритет, чем поток, претендукиции на ее 
получение. Низкоприоритетнми поток может вообнце не получитБ шансов на вбг- 
полнение, то естћ просто зависнутБ. Windows иногда на короткое времи динами- 
чески повБпнает приоритет потоков. Длл потоков, исполвзуклцих блокирование 
с зацикливанием, даннвш режим следует отклгочитб. Зто делаетсл при помогци 
своиств PnionityBoostEnabled классов System.Diagnostics.Pnocess и System. 
Diagnostics . PnocessThnead. Блокирование c зацикливанием нагиперпотоковБ 1 Х 
машинах также свизано с проблемами. Длл их решенил код блокированин с за- 
цикливанием часто наделлетсл дополнителвнои логикои. Однако и не хотел 6 бг 
вдаватБСи в детали, так как зта логика доволбно бн> 1 Стро меннетсл. Могу сказатБ 
толбко, что FCL поставлиетсл вместе со структурои System . Thneading . SpinWait, 
котораи заклгочает в себл всго необходимуго логику. 

Задержка в обработке потока 

Хитроств состоит в том, чтобвг иметБ поток, умегогции заставитБ ресурс на времн 
приостановитБ исполнение зтого потока, что6бг другои поток, обладагогции в даннвш 
момент ресурсом, завершилсн и освободил место. Длн зтого структура SpinWait 
вБгзБгвает методБг Sleep, Yield и SpinWait класса Thnead. Коротко опишем даншле 
методБг. 

Поток может сообгцитБ системе, что в течение некоторого времени его не нужно 
планироватБ на исполнение. Зта задача решаетси статическим методом Sleep: 

public static void Sleep(Int32 millisecondsTimeout); 
public static void Sleep(TimeSpan timeout); 

Поток заставлнет метод приостановитБ работу на указанное времн. Вбгзов метода 
Sleep позволнет потоку доброволвно убратБ напоминание о времени своего испол- 
ненгш. Система забирает поток у планировгцика примерно на указанное времн. То 
еств если вбг говорите системе, что метод хочет приостановитБ работу на 100 мс, он 
будет приостановлен примерно на зто времн, но возможно пробудет в состоингш 
покол на несколвко секунд менкше или болБше. Не забБгваите, что Windows не 
ивлиетсл операционнои системои реалвного времени. Поток, скорее всего, про- 
будитсл в указанное времл, но по болвшому счету времн его пробужденгш зависит 
от осталБНБгх происходшцих в системе процессов. 

Можно передатв параметру millisecondsTimeout метода Sleep значение 
System . Thneading . Т imeout . Inf inite (определенное как -1). В резулктате поток 
окажетси заблокированнБш на неограниченное времн. При зтом он будет сугце- 
ствоватв, и вб1 в лгобои момент сможете восстановитв его стек и ндро. Передача 
в метод Sleep значенгш 0 сообгцит системе, что вБгзБшагогции поток освобождает 
ее от его исполненгш и заставлнет запланироватв другои поток. Впрочем, систе- 
ма при отсутствии доступнвгх длл планированил потоков такого же или более 
вбгсокого приоритета может снова запланироватв исполнение потока, толбко что 
вБгзвавшего метод Sleep. 



840 Глава 29. Примитивние конструкции синхронизации потоков 


Поток может также попроситћ Windows запланироватБ длн текушего процессора 
другои поток, вБ13вав метод Yield класса Thread: 

public static Boolean Yield(); 

При наличии другого потока, готового работатБ на данном процессоре, метод 
возврагцает значение true, времн жизни вБИвавшего его потока считаетси завер- 
шеннБш, а в течение одного такта исполБзуетсл другои вБ 1 бранш>ш поток. После 
зтого вБ13вавшии метод Yield поток снова попадает в расписание и начинает ра- 
ботатв в течение следугогцего такта. При отсутствии потоков, на которБ 1 е можно 
переклгочитБСи, метод Yield возврагцает значение false, и вв 1 звавшии его поток 
продолжает исполнитбси. 

Метод Yield дает шанс исполнитб ожидагогцие своего процессорного времени 
потоки равного или более низкого приоритета. Поток ввгоБшает даннБш метод, если 
ему требуетсл ресурс, которБш в настоигцее времи владеет другои поток. Он рас- 
считивает на то, что Windows поставит обладагогции ресурсом в даннвпг момент 
поток в очередв планировгцика, освободив тем самвш доступ. В резулнтате, когда 
вБгзвавшии метод Yield поток снова начнет исполиитбси, доступ к ресурсу может 
получитБ уже он. 

Сугцествует BBi6op между вбгоовом методов Thread . Sleep (0) и Thread . Sleep (1). 
В первом случае потокам с низким приоритетом не дагот исполнитбси, в то времи 
как метод Thread.Sleep(l) вклгочает принудителБное переклгочение контекста, 
и Windows погружает поток в спнгцее состонние более чем на 1 мс, что обусловлено 
разрешением внутреннего системного таимера. 

На гиперпотоковБ 1 х процессорах в каждвпг момент времени может вбшолннтбсн 
толкбо один поток. И когда на таких процессорах поток входит в состонние заци- 
кливангш, нужно принудителвно остановитн текугции поток, позволив исполннтбсн 
другому. Поток может остановитБСн сам, дав гиперпотоковому процессору возмож- 
ностб переклгочитБСи на другие потоки, вБИБшан метод SpinWait класса Thread: 

public static void SpinWait(Int32 iterations); 

Bbi.si.i isan зтот метод, bki фактически вБшолннете специалБнуго инструкциго 
процессора. Она не заставлиет Windows делатв какуго-либо работу (операционнан 
система уверена, что она уже запланировала длн процессора два потока). В случае 
если гиперпотоковБш процессор не исполБзуетсн, зта специалБнан инструкцин 
просто игнорируетсл. 

ПРИМЕЧАНИЕ 

4to6w лучше познакомишса с даннБ 1 ми методами, почитаите про их Win32- 
зквивалентБ!: Sleep, SwitchToThread и YieldProcessor. ДополнителБнме сведенил 
о настроике разрешенил системного таимера вм получите при знакомстве с Win32- 
функцичми timeBeginPeriod и timeEndPeriod. 
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В FCL сушествует также структура System.Threading.SpinLock, сходнаи 
с показаннмм ранее классом SimpleSpinLock. Она отличаетсл исполвзованием 
структурм SpinWait сцелБЈОповмшенил производителБности. Структура SpinLock 
поддерживает времн ожиданил. Интересно отметитБ, что обе структурБ 1 — моп 
SimpleSpinLock и SpinLock в FCL — относлтсл к значимвш типам. То естБ они 
ивлиготсл облегченнБши обвектами, требукпцими мииималБНБГх затрат памнти. 
Перечислением SpinLock имеет смбгсл полБЗОватБСи, если вам нужно, к примеру, 
свнзатв блокировку с каждвш алементом коллекции. Но при зтом нужно следитп за 
тем, что6б1 зкземплирБ1 SpinLoc k никуда не передавалисБ, потому что они при зтом 
копируготси, из-за чего вси синхронизации тернетсл. И хотн bbi можете определитБ 
зкземплирнБ 1 е поли SpinLock, не помечаите их как предназначешпле толбко длн 
чтенгш (readonly), посколБку при манипулицгшх с блокировкои их внутреннее 
значение должно меннтБСн. 

УниверсалБнми lnterlocked -паттерн 

Многие полБЗОватели, познакомившисБ с Interlocked -методами, удивлнготсн, поче- 
му специалистБ1 Microsoft не разработали дополнителБНБ1х методов подобного рода, 
подходлгцих дли болвшего количества ситуации. К примеру, в классе Interlocked 
6б1ли 6б1 полезнБ 1 методБг Multiple, Divide, Minimum, Maximum, And, Or, Хог и многие 
другие. Однако вместо зтих методов можно исполБЗОватБ хорошо известнБШ шаблон, 
позволнгогции методом Interlocked .CompareExchange атомарно вбшолннтб лгобБге 
операции со значенгшми типа Int32. А так как сугцествугот перегруженнвш версии 
зтого метода длн типов Int64, Single, Double, Object, a также дли обобгценного 
ссбшочного типа, шаблон может работатБ и со всеми зтими типами. 

Вот пример создангш на основе шаблона атомарного метода Maximum: 

public static Int32 Maximum(ref Int32 target, Int32 value) { 

Int32 currentVal = target^ startVal, desiredVal; 

// Параметр target может исполвзоватБСп другим потоком, 

// его трогатБ не стоит 
do { 

// ЗаписБ началБного значенил зтои итерации 
startVal = currentVal; 

// Втчисление желаемого значенин в контексте startVal и value 
desiredVal = Math.Max(startVal., value); 

// ПРИМЕЧАНИЕ . Здесц поток может бмтц прерван! 

// if (target == startVal) target = desiredVal 

// Возврацение значенил, предшествуккцего потенциалцнмм измененилм 
currentVal = Interlocked.CompareExchange( 
ref target, desiredVal, startVal); 

// Если началцное значение на зтои итерации изменилосц, повторитц 
} while (startVal != currentVal); 


продолжение & 



842 Глава 29. Примитивние конструкции синхронизации потоков 


// Возврацаем максималвное значение, когда поток пнтаетсн его присвоити 
return desiredVal; 

} 

Даваите посмотрим, что здесв происходит. В момент, когда метод начинает 
вмполннтбси, переменнан currentVal инициализируетси значением параметра 
ta rget. Затем внутри цикла то же самое началћное значение получает переменнан 
startVal. При помогци зтои последнеи переменнои bhi можете вбшолнитб .tioopjIC 
нужнБ 1 е вам операции. Они могут 6 bitb краине сложнбши и состонтб из тб 1 Слч 
строк кода. Но в итоге должен 6 bitb сформирован резулвтат, которБпг помегцаетсл 
в переменнуто desiredVal. В моем примере просто сравниваготсл переменнБге 
startVal и value. 

Пока операцин вБшолниетсл, значение target может 6 бгтб изменено другим 
потоком. Зто маловеронтно, но теоретически не исклгочено. Если зто произоидет, 
значение переменнои derivedVal окажетсл основаннвш на старом значении пере- 
меннои startVal, а не на текугцем значении параметра target, а следователкно, 
мб 1 не должнбг менитБ зтот параметр. ГарантироватБ, что значение параметра 
target поменнетсл на значение переменнои desiredVal при условии, что никакои 
другои поток не поменнет его за спинои нашего потока, можно с помогцбго метода 
Interlocked.CompareExchange. Он провериет, совпадает ли значение параметра 
target со значением переменнои startVal (а именно его mbi предполагаем у па- 
раметра target перед началом вБшолненин операции). Если значение параметра 
target не поменнлосБ, метод CompareExchange замениет его новбш значением 
переменнои desiredVal. Если же изменешш произошли, метод CompareExchange 
не трогает параметр target. 

Метод CompareExchange возврагцает значение параметра target на момент 
своего вБгзова, которое mi.i помегцаем в переменнуго currentVal. Затем перемен- 
наи startVal сравниваетсн с новбш значением переменнои currentVal. В случае 
совпаденгш поток не меннет параметр target за нашеи спинои, зтот параметр 
содержит значение переменнои desiredVal, цикл while прекрагцает свого работу, 
и метод возврагцает управление. Если же значенгш не совпадагот, значит, другои 
поток поменнл значение параметра target, позтому параметру не 6 бшо присвоено 
значение переменнои desiredVal, цикл переходит к следугогцеи итерации и пробует 
снова вбшолнитб операциго на зтот раз с новбш значением переменнои currentVal, 
отражагогцеи измененгш, iiiieceuiii.ie посторонним потоком. 

Лично л исполБЗОвал даннвги шаблон оченБ часто и даже создал инкапсулиро- 
вавшии его обобгценнвш метод Morph 1 : 

delegate Int32 Morpher<TResult л TArgument>( 

Int32 startValue, TArgument argument, 
out TResult morphResult); 


1 Очевидно, что из-за метода обратного вмзова morpher метод Morph хуже в плане про- 
изводителБности. Что6бг исправитБ ситуацшо, сделаите код подставлнемБгм (inline), как 
в примере Maximum. 
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static TResult Morph<TResult, TArgument>( 
ref Int32 target, TArgument argument, 

Morpher<TResult, TArgument> morpher) { 

TResult morphResult; 

Int32 currentVal = target, startVal, desiredVal; 
do { 

startVal = currentVal; 

desiredVal = morpher(startVal, argument, out morphResult); 
currentVal = Interlocked.CompareExchange( 
ref target, desiredVal, startVal); 

} while (startVal != currentVal); 
return morphResult; 


Конструкции режима лдра 

Длн синхронизации потоков в Windows сундествует нссколбко конструкции режима 
ндра. Они работагот намного медленнее конструкции полБзователБского режима, 
так как требугот координации со сторонв 1 операционнои системм. Кроме того, 
каждБШ ВБ130В метода длн обЂекта лдра заставлнет вБИБшагогции поток переити из 
управлнемого в машиннБпг код, затем в код режима лдра, после чего возврагцаетсл 
назад. Такие переходм требугот много процессорного времени и их частое вбшол- 
нение значителБно снижает производителБностБ приложенгш. 

Впрочем, у конструкции режима ндра сстб и свои преимугцества перед конструк- 
цинми полвзователБСКого режима: 

□ Если конструкцил режима лдра вБ 1 ивлиет конкуренциго за ресурс, Windows 
блокирует проигравшии поток, останавливан зацикливание, которое ведет к на- 
прасному расходованиго ресурсов процессора. 

□ Конструкции режима ндра могут осугцествлитв взаимнуго синхронизациго не- 
управлнемБгх и управлиемБгх потоков. 

□ Конструкцгш режима лдра умегот синхронизироватБ потоки различнБгх про- 
цессов, запугценнвгх на однои машине. 

□ Конструкции режима ндра можно наделитБ атрибутами безопасности, ограни- 
чиван несанкционированнБп! доступ к ним. 

□ Поток можно заблокироватБ, пока не станут доступнБг все конструкции режима 
ндра или пока не станет доступна хотл 6 bi одна такаи конструкцгш. 

□ Поток можно заблокироватБ конструкциеи режима ндра, указав времч ожидангш; 
если за указанное времи поток не получит доступа к нужному ему ресурсу, он 
будет разблокирован и сможет вбшолнитб другие задангш. 

К примитивнБгм конструкцгшм синхронизации потоков в режиме идра от- 
носнтсл собитил (events) и семафори (semaphores). На их основе строитсл 
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более сложнме конструкцин аналогичного назначенил, например мћттекси 
(mutex). Более полнуго информациго о них вм наидете в моеи книге «Windows via 
С/С++» (Microsoft Press, 2007). 

В пространстве имен System . Threading сугцествует абстрактнми базовми класс 
WaitHandle. Он играет ролБ оболочки длл дескриптора ндра Windows. В FCL име- 
етси несколБКО производнмх от него классов. Все они определенм в пространстве 
имен System.Threading и реализуготси библиотекои MSCorLib.dll. Исклгочением 
нвллетсл класс Semaphore, реализованнми в библиотеке System.dll. Вот как вм- 
гллдит иерархин зтих классов: 

l/JaitHandle 

EventWaitHandle 

AutoResetEvent 

ManualResetEvent 

Semaphore 

Mutex 

B базовом классе WaitHandle имеетсл поле SafeWaitHandle, содержагцее де- 
скриптор идра Win32. Зто поле инициализируетсн в момент создангш класса, про- 
изводного от WaitHandle. Кроме того, класс WaitHandle предоставллет открмтме 
методм, которме наследуготсл всеми производнмми классами. Каждми из вмзмва- 
еммх конструкцгшми режима ндра методов обеспечивает полнуго загциту памити. 
Вот наиболее интереснме открмтме методм класса WaitHandle (перегруженнме 
версии некотормх методов не показанм): 

public abstract class WaitHandle : MarshalByRefObject, IDisposable { 

// Реализацил WaitOne вмзувает функции Win32 WaitForSingleObjectEx. 
public virtual Boolean WaitOne(); 

public virtual Boolean WaitOne(Int32 millisecondsTimeout); 
public virtual Boolean WaitOne(TimeSpan timeout); 

// Реализацив WaitAll вмзувает функцига Win32 WaitForMultipleObjectsEx 
public static Boolean WaitAll(WaitHandle[] waitHandles); 
public static Boolean WaitAll(WaitHandle[] waitHandles, 

Int32 millisecondsTimeout); 

public static Boolean WaitAll(WaitHandle[] waitHandles, TimeSpan timeout); 

// Реализацил WaitAny вмзувает функции Win32 WaitForMultipleObjectsEx 
public static Int32 WaitAny(WaitHandle[] waitHandles); 
public static Int32 WaitAny(WaitHandle[] waitHandles, 

Int32 millisecondsTimeout); 

public static Int32 WaitAny(WaitHandle[] waitHandles, TimeSpan timeout); 
public const Int32 WaitTimeout = 258; // Возврацаетсл WaitAny 

// в случае таим-аута 

// Реализацил Dispose вБ13мвает функцик) Win32 
// CloseHandle - НЕ BbBblBAMTE ЕЕ ! 
public void Dispose(); 


} 
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Здесћ следует сделатБ несколБко замечании: 

□ Метод WaitOne класса WaitHandle блокирует текутции поток до активизации 
обиектом ндра. Он iibi3i.i наст Win32-(|)y пкцп io WaitForSingleObjectEx. Значение 
true возвратцаетсл, если обвект 6 бш активизирован. Если же времн ожиданин 
истекло, возвратцаетси значение f alse. 

□ Статическии метод WaitAll класса WaitHandle заставлиет ВБГЗБшаклции поток 
ждатБ активизации всех обвектов ндра, указаннБ 1 х в массиве WaitHandle[ ]. 
Если все обвектБ 1 6 бши активизированБц возвраидаетсл значение true, в случае 
же истечентш времени ожидании возвратцаетсн значение f alse. /[aiuibiii метод 
вБ13Бшает Win32-^yHKuino WaitForMultipleObjectsEx, передаваи параметру 
bWaitAll значение TRUE. 

□ Статическии метод WaitAny класса WaitHandle заставлиет вБ13Б1ватотции 
поток ждатБ активизации лтобого из обвектов идра, указаннБ 1 х в массиве 
WaitHandle [ ]. Возвратценное значение типа Int32 цвлиетсл индексом ак- 
тивизированного злемента массива. Если в процессе ожидантш сигнала не 
поступтшо, возвратцаетси значение WaitHandle.WaitTimeout. ДаннБпт метод 
вБ13Бшает Win32-^yHKuino WaitForMultipleObjectsEx, передаваи параметру 
bWaitAll значение FALSE. 

□ Метод Dispose закрвшает дескриптор обт.екта ндра. Во внутреннеи реализации 
зти методБ 1 вБ13Бшатот функцтпо Win32 CloseHandle. ВмзБшатБ Dispose в коде 
можно толбко в том случае, если bbi абсолтотно уверенБц что обвект лдра не 
исполБзуетсл другими потоками. Зто обстоителБСтво силбио затрудниет напи- 
сание и тестирование кода, позтому н настонтелБно не рекомендуто вБИБшатБ 
Dispose; просто позволбтс уборгцику мусора вбшолнитб cboio работу. Он сможет 
определитБ, когда обт.ект не исполБзуетсн, и уничтожит его. 


ПРИМЕЧАНИЕ 

В некоторБ 1 х случапх при блокировке потока из однопоточного отделенил (apartment) 
возможно пробуждение потока длл обработки сообидении. Например, заблокиро- 
ваннии поток может проснутБса дпл обработки Windows-coo6meHnn, отправленного 
другим потоком. Зто делаетсл длл совместимости с моделБК) СОМ. Длл 6олбшин- 
ства приложении зто не проблема. Но если ваш код в процессе обработки сообиде- 
нил запрет другои поток, может случитБСл взаимнал блокировка. Как вн увидите 
в главе 29, все гибриднБ 1 е блокировки тоже могут визиватБ данние методи, так что 
вишесказанное верно и длл них. 


В прототипе версии WaitOne, WaitAll и SignalAndWait, не приниматотцих па- 
раметр timeout, должно 6 bitb указано возвратцаемое значение void, а не Boolean. 
В противном случае методБ 1 6 б 1 всегда возвратцали значение true из-за предпола- 
гаемого бесконечного времени ожидантш (Sy stem . Threading . Т imeout . Inf inite). 
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Так что при вмзове лгобого из зтих методов нет нуждм проверитБ возврагцаемое 
им значение. 

Как уже упоминалосБ, классБ 1 AutoResetEvent, ManualResetEvent, Semaphore 
и Mutex НВЛИ 10 ТСН производнвши от класса WaitHandle, то естк наследугот методБ 1 
зтого класса и их поведение. Впрочем, зти классБ 1 обладагот и собственнБши мето- 
дами, о которБ1х мб1 сеичас и поговорим. 

Во-первБ 1 х, конструкторБ 1 всех зтих классов вБ13Б1вагот Win32-^yHKu,nro 
CreateEvent (передаван в параметре bManualReset значение FALSE), CreateEvent 
(передавал в параметре bManualReset значение TRUE), CreateSemaphore или 
CreateMutex. Значение дескриптора, возврагцаемого при таких ввгоовах, сохраннетсн 
в закрвмом поле SafeWaitHandle, определенном в базовом классе WaitHandle. 

Во-вторв 1 х, классБ 1 EventWaitHandle, Semaphore и Mutex предлагагот статические 
методБ 1 OpenExisting, вБИБшагошие Win32-^yHKunro OpenEvent, OpenSemaphore 
или OpenMutex, передаван eii аргумент типа String с именем сугцествугогцего ндра. 
Значение дескриптора, возврагцаемого при таких ввгоовах, сохраннетсл во вновб 
созданном обвекте, возврагцаемБш методом OpenExisting. При отсутствии лдра 
с указаннвш именем генерируетси исклгочение WaitHandleCannotBeOpenedExcep- 
tion. 

Конструкции режима лдра часто исполБзуготсп длн созданип приложении, ко- 
Topiiie в лгобои момент времени могут сугцествоватв толбко в одном зкземплнре. 
Примерами таких приложении нвлнготсн Microsoft Office Outlook, Windows Live 
Messenger, Windows Media Player Windows Media Center. Вот как реализоватв такое 
приложение: 

using System; 

using System.Threading; 

public static class Program { 
public static void Main() { 

Boolean createdNew; 

// ПмтаемсА создатБ обБект лдра с указанним именем 
using (new Semaphore(0, 1, "SomeUniqueStringIdentifyingMyApp", 
out createdNew)) { 
if (createdNew) { 

// Зтот поток создает ндро, так что другие копии приложенил 
// не могут запускатисн. Вкшолнлем осталинук) части приложенил... 

} else { 

// Зтот поток открмвает суцествукицее лдро с тем же именем; 

// должна запуститБсл другал копил приложенил. 

// Ничего не делаем, ждем возвраценил управленил от метода Main, 

// чтобм завершити вторук) копит приложенил 

} 

} 

} 

} 
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В зтом фрагменте кода исполБзуетсн класс Semaphore, но с таким же успехом 
можно 6бшо восполБЗОватБСи классом EventWaitHandle или Mutex, так как предла- 
гаемое обвектом поведение не требует синхронизации потока. Однако н исполвзук) 
преимугцество такого поведенгш при создании обвектов ндра. Даваите посмотрим, 
как работает показаннвш код. Представим, что две копии процесса запустилисв 
одновременно. Каждому процессу соответствует его собственнвш поток, и оба по- 
тока попБгтаготси создатБ обвект Semaphore с одним и тем же именем (в моем при- 
мере SomeUniqueStringIdentifyingMyApp). Лдро Windows гарантирует создание 
обвекта лдра с указаннвш именем толбко одним потоком; переменнои с reatedNew 
зтого потока будет присвоено значение true. 

В случае со вторвш потоком Windows обнаруживает, что обвект ндра с указаннвш 
именем уже сугцествует; соответственно, потоку не позволнетсл создатв егце один 
обвект. Впрочем, продолжив работу, зтот поток может получитв доступ к тому же 
обвекту идра, что и поток первого процесса. Таким способом потоки из различнвгх 
процессов взаимодеиствугот друг с другом через единое лдро. Но в данном случае 
поток второго процесса видит, что его переменнои createdNew присвоено значение 
f alse. Таким образом он узнает о том, что перван копгш процесса запугцена, позтому 
втораи копгш немедленно завершает свого работу. 


Собмтил 


Собитил (events) представлнгот собои переменнвге типа Boolean, находлгциесл 
под управлением лдра. Ожидагогции собвгтгш поток блокируетсл, если оно имеет 
значение f alse, и освобождаетсл в случае значенгш true. Сугцествует два вида со- 
бвгтии. Когда собљггие с автосбросом имеет значение true, оно освобождает всего 
один заблокированнБги поток, так как после освобожденгш первого потока идро 
автоматически возврагцает собвгтиго значение f alse. Если же значение true имеет 
собвгтие с ручнБш сбросом, оно освобождает все ожидагогцие зтого потоки, так как 
в данном случае лдро не присваивает ему значение f alse автоматически, в коде зто 
должно 6бгтб сделано в лвном виде. Вот как вбггллдлт классБг, свлзаннБге с собБгтгшми: 


public class EventWaitHandle 
public Boolean Set(); // 
// 

public Boolean Reset(); // 
// 

} 


: WaitHandle { 

Boolean присваиваетсл true; 
всегда возврацает true 
Boolean присваиваетсв false; 
всегда возврацает true 


public sealed class AutoResetEvent : EventWaitHandle { 
public AutoResetEvent(Boolean initialstate); 

} 

public sealed class ManualResetEvent : EventWaitHandle { 
public ManualResetEvent(Boolean initialState); 

} 
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С помшцбк) собмтии с автосбросом можно легко реализоватБ блокировку 
в рамках синхронизации потоков, поведение которого сходно с поведением ранее 
показанного класса SimpleSpinLock: 

internal sealed class SimpleWaitLock : IDisposable { 
private readonly AutoResetEvent m_available; 

public SimpleWaitLock() { 

m_available = new AutoResetEvent(true); // ИзначалБно свободен 

} 

public void Enter() { 

// Блокирование на уровне лдра до освобожденив ресурса 
m_available.WaitOne(); 

} 

public void Leave() { 

// Позволлем другому потоку обратитвсл к ресурсу 
m_available.Set( ); 

} 

public void Dispose() { m_available.Dispose(); } 

} 

Класс SimpleWaitLock примениетсн так же, как мм исполБЗОвали бм класс 
SimpleSpinLock. Более того, внешне он ведет себн совершенно так же; авот произ- 
водителБностБ двух вариантов блокировки отличаетсл кардиналвнБш образом. При 
отсутствии конкуренции за блокировку класс SimpleWaitLock работает намного 
медленнее класса SimpleSpinLock, посколвку каждкш вбиов его методов Enter 
и Leave заставлнет поток совершитв переход из управлнемого кода в ндро и обратно. 
Тем не менее при наличии конкуренции проигравшии поток блокируетсл лдром 
и не зацикливаетсл, не даваи впустуго тратитв ресурсБ 1 процессора. Имеите в виду, 
что переходами из управлнемого кода в идро и обратно сопровождаетсл также соз- 
дание обвекта AutoResetEvent и вбгоов дли него метода Dispose, что отрицателвно 
сказБшаетсл на производителБности. Впрочем, зти вб 130 вб 1 совершаготси редко, так 
что не стоит слишком силбно беспокоитБСн по зтому поводу. 

4to6bi продемонстрироватБ разницу в производителвности, и написал следуго- 
гции код: 

public static void Main() { 

Int32 х = 0; 

const Int32 iterations = 10000000; // 10 миллионов 

// Сколбко времени заимет инкремент х 10 миллионов раз? 

Stopwatch sw = Stopwatch.StartNew(); 
for (Int32 i = 0; i < iterations; i++) { 
x++; 

} 

Console.WriteLine("Incrementing х: {0:N0}", sw.ElapsedMilliseconds); 


// Скол бко времени заимет инкремент х 10 миллионов раз, если 
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// добавитБ внзов ничего не делакицего метода? 
sw.Restart( ); 

for (Int32 i = 0; i < iterations; i++) { 

M(); x++; M(); 

} 

Console.WriteLine("Incrementing х in M: {0:N0}"j sw.ElapsedMilliseconds); 

// Сколико времени заимет инкремент х 10 миллионов раз, если 
// добавити Bbi 30 B неконкурируклцего обнекта SimpleSpinLock? 

SpinLock sl = new SpinLock(false); 
sw.Restart(); 

for (Int32 i = 0; i < iterations; i++) { 

Boolean taken = false; sl.Enter(ref taken); x++; sl.Exit(); 

} 

Console.WriteLine("Incrementing х in SpinLock: {0:N0}", 
sw.ElapsedMilliseconds); 

// Сколцко времени заимет инкремент х 10 миллионов раз, если 
// добавити Bbi 30 B неконкурирук)цего обиекта SimpleWaitLock? 
using (SimpleWaitLock swl = new SimpleWaitLock()) { 
sw.Restart(); 

for (Int32 i = 0; i < iterations; i++) { 
swl.Enter(); x++; swl.Leave(); 

} 

Console.WriteLine( 

"Incrementing х in SimpleWaitLock: {0:N0}", sw.ElapsedMilliseconds); 

} 

} 

[Methodlmpl(MethodlmplOptions.Nolnlining)] 

private static void M() { /* Зтот метод толико возврацает управление */ } 

Запустив зтот код, л получил следукпции резулБтат: 

Incrementing х: 8 Самни бмстрни 

Incrementing х in М: 69 Медленнее ~9 раз 

Incrementing х in SpinLock: 164 Медленнее ~21 раз 

Incrementing х in SimpleWaitLock: 8,854 Медленнее ~1107 раз 

Как легко заметитБ, простои инкремент х занимает всего 8 мс. Простои вбиов 
метода до и после инкремента увеличивает времи вБшолненин в 9 раз! Ввшолне- 
ние кода в методе, которвш исполвзует конструкции полБЗОвателБСКого режима, 
заставило код работатв в 21 (164/8) раз медленнеи. А теперв обратите внимание, 
на сколбко замедлиласБ программа при вставке в нее конструкции режима лдра. 
Резулвтат достигаетсл в 1107 (8854/8) раз медленнеи! Позтому если можете избе- 
жатв синхронизации потоков, избегаите ее. Если без нее не обоитисв, задеиствуите 
конструкции полвзователБСКого режима. Конструкции режима лдра следует ис- 
полБЗОватБ лишб в самом краинем случае. 
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Семаформ 

Семафори (semaphores) также представлнгот собои обнчнне переменнме типа Int32, 
управлиемне лдром. Ожидагошии семафора поток блокируетсл при значении 0 
и освобождаетсн при значениих бо. њше 0. При снитии блокировки с ожидагошего 
семафора потока ндро автоматически вмчитает единицу из счетчика. С семафорами 
свизано максималБное значение типа Int32, которое ни при каких обстоителв- 
ствах не могут превмситБ текугцие показании счетчика. Вот как вбшлндит класс 
Semaphore: 


public sealed class Semaphore : WaitHandle { 

public Semaphore(Int32 initialCount^ Int32 maximumCount); 
public Int32 Release(); // Внзмвает Release(l); 

// возврацает предмдуцее значение счетчика 
public Int32 Release(Int32 releaseCount); // Возврацает предмдуцее 

// значение счетчика 


} 


Подб1тожим, каким образом ведут себн зти три примитива режима ндра: 

□ При наличии несколвких потоков в режиме ожидании собљггие с автосбросом 
освобождает толшо один из них. 


□ Собв 1 тие с ручнБш сбросом снимает блокировку со всех ожидагогцих его по- 
токов. 


□ При наличии несколвких потоков, ожидагогцих семафора, его понвление снимает 
блокировку с потоков releaseCount (здесв releaseCount — зто аргумент, пере- 
даннБш методу Release класса Semaphore). 

То естБ получаетсл, что собБгтие с автосбросом зквивалентно семафору, мак- 
сималБное значение счетчика которого равно единице. Разница между ними 
состоит в том, что метод Set длл собвгтил с автосбросом можно ввгзватБ много 
раз, но каждБш раз освобождатБСн будет всего один поток, в то времл как много- 
кратнвш вб130в метода Release каждвги раз увеличивает на единицу внутреннии 
счетчик семафора, давал возможностб сннтб блокировку с болвшего количества 
потоков. Однако следует помнитб, что при вБгзове метода Release длл семафора, 
показание счетчика которого уже равно максималвному, генерируетсн исклгочение 
SemaphoreFullException. 

При помогци семафоров можно повторно реализоватв класс SimpleWaitLock 
таким образом, что несколБКим потокам будет предоставллтБСл одновременнБпг 
доступ к ресурсу (что безопасно толбко при условгш, что все потоки исполвзугот 
ресурс в режиме толбко длл чтенгш): 

public sealed class Simplel/JaitLock : IDisposable { 
private Semaphore m_AvailableResources; 


public SimpleWaitLock(Int32 maximumConcurrentThreads) { 
m AvailableResources = 
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new Semaphore(maximumConcurrentThreads, maximumConcurrentThreads) ; 

} 

public void Enter() { 

// Ожидаем в ддре доступа к ресурсу и возврацаем управление 
m_AvailableResources.WaitOne() ; 

} 

public void Leave() { 

// Зтому потоку доступ болише не нужен; его может получити другои поток 
m_ AvailableResources . Release( ); 

} 

public void Dispose() { m_AvailableResources.Close(); } 

} 


MbioTeKCbi 

Mbmmeuc (mutex) предоставлнет взаимно исклгочакшдук) блокировку. Он функцио- 
нирует аналогично обвекту AutoResetEvent (или обвекту Semaphore со значением 
счетчика 1 ), так как все три конструкции за один раз освобождагот всего один ожи- 
дагогции поток. Вот как вмгллдит класс Mutex: 

public sealed class Mutex : WaitHandle { 
public Mutex(); 
public void ReleaseMutex(); 

} 

Мг>готексБ1 снабженБг дополнителћнои логикои, что делает их более сложнбши 
по сравнениго с другими конструкцилми. Во-первБ1х, обвектБ1 Mutex сохраннгот 
информациго о том, какие потоки ими владегот. Длн зтого они запрашивагот иден- 
тификатор потока (Int32). Если поток вБгзвшает метод ReleaseMutex, обвект Mutex 
сначала убеждаетсл, что зто именно владегогции им поток. Если зто не так, состонние 
обвекта Mutex не меннетсн, а метод ReleaseMutex генерирует исклгочение System . 
ApplicationException. Если владегогции обвектом Mutex поток по какои-то при- 
чине завершаетсл, пробуждаетсн другои поток, ожидагогции мБготекса, и генерирует 
исклгочение System . Threading . AbandonedMutexException. 06бшно зто исклгочение 
остастси необработаннБгм, что приводит к завершениго всего процесса. И зто хо- 
рошо, ведв новБги поток получает обвект Mutex, старБги владелец которого вполне 
мог 6бгтб финализирован перед завершением обновленгш загцигцаемБгх мБготексом 
даннБгх. Если новбги поток перехватит исклгочение AbandonedMutexException, он 
может попБгтатвси получитБ доступ к поврежденнБгм даннБгм, что приведет к не- 
предсказуемвш резулБтатам и проблемам безопасности. 

Кроме того, обвектБг Mutex управлигот рекурсивнвш счетчиком, указБшагогцим, 
сколбко раз поток-владелец уже владел обвектом. Если поток владеет мвготексом 
в настонгцни момент и ожидает его егце раз, рекурсивнБш счетчик увеличиваетсл на 
единицу, и потоку разрешаетсл продолжитв вБгполнение. При вБгзове потоком метода 
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ReleaseMutex рекурсивнми счетчик уменБшаетсл на единицу. И толбко после того, 
как его значение достигнет 0, владелБцем мБкзтекса может статк другои поток. 

Болбшинство полвзователеи не в восторге от зтои дополнителвнои логики. Про- 
блема в том, что зти <<возможности» iimciot cboio цену. Обвекту Mutex требуетсл 
дополнителБнал памитн длл храненин идентификатора потока и рекурсивного 
счетчика. И главное, код обвекта Mutex должен управлитв зтои информациеи, что 
тормозит блокировку. Если приложеншо понадобнтсн зти дополнителБнвге возмож- 
ности, его код сможет реализоватв их самостоителБно, не встраиван в обвект Mutex. 
Позтому многие разработчики стараготси обходитвсн без мБГОтексов. 

Обвшно рекурсивное блокирование имеет место, если запертвш метод вБИБшает 
другои метод, также требугогции блокировании. Зто демонстрирует следугогции 
код: 

internal class SomeClass : IDisposable { 

private readonly Mutex m_lock = new Mutex(); 

public void Methodl() { 
m_lock.WaitOne(); 

// Делаем что-то... 

Method2(); // Метод Method2, рекурсивно получаклции право на блокировку 
m_lock.ReleaseMutex() ; 

} 

public void Method2() { 
m_lock.WaitOne(); 

// Делаем что-то... 
m_lock.ReleaseMutex(); 

} 

public void Dispose() { m_lock.Dispose(); } 

} 

B приведенном фрагменте код, исполБзугогции обвект SomeClass, может вбн 
зватБ метод Methodl, получагогции обвект Mutex. Зтот код вБшолнчет какуго-то 
безопаснуго в отношении потоков операциго, а затем ввгоБшает метод Method2, также 
вБшолннгогции какуго-то безопаснуго в отношении потоков операциго. Благодарн 
поддержке рекурсии обвектом Mutex поток сначала дваждБ 1 блокируетсл, а потом 
дваждБ1 разблокируетсн, и толбко после зтого мнготекс может переити к новому по- 
току. Если 6 bi класс SomeClass исполБЗОвал вместо мвготекса обвект AutoResetEvent, 
при вБ130ве метода WaitOne поток 6 бш 6 б 1 заблокирован. 

Рекурсивное блокирование можно легко организоватв при помогци обвекта 
AutoResetEvent: 

internal sealed class RecursiveAutoResetEvent : IDisposable { 
private AutoResetEvent m_lock = new AutoResetEvent(true); 
private Int32 m_owningThreadId = 0; 
private Int32 m_recursionCount = 0; 
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public void Enter() { 

// Получаем идентификатор внзивакицего потока 

Int32 currentThreadld = Thread.CurrentThread.ManagedThreadld; 

// Если внзмвак) 1 ции поток блокируетсл., 

// увеличиваем рекурсивнши счетчик 
if (m_owningThreadId == currentThreadld) { 
m_recursionCount++; 
return; 

} 

// Вц|зшвак)ции поток не имеет блокировки, ожидаем 
m_lock.WaitOne(); 

// Tenepb внзмваклции поток блокируетсл, инициализируем 
// идентификатор зтого потока и рекурсивнни счетчик 
m_owningThreadId = currentThreadld; 
m_recursionCount = 1; 

} 

public void Leave() { 

// Если вшзмвакиции поток не лвллетсн владелццем блокировки, 

// произошла ошибка 

if (m_owningThreadId != Thread.CurrentThread.ManagedThreadld) 
throw new InvalidOperationException(); 

// Вшчитаем единицу из рекурсивного счетчика 
if (--m_recursionCount == 0) { 

// Если рекурсивнши счетчик равен 0 , 

// ни один поток не владеет блокировкои 
m_owningThreadId = 0; 

m_lock.Set(); // Пробуждаем один ожидакиции поток (если такие естц) 

} 

} 

public void Dispose() { m_lock.Dispose(); } 

} 

Хотн поведение класса RecursiveAutoResetEvent идентично классу Mutex, обв- 
ект RecursiveAutoResetEvent при попмтке потока получитБ право на рекурсивное 
блокирование будет иметБ значителБно лучшуго производителБностБ, так как про- 
цедурБ 1 отслеживанин потока-владелБца и рекурсии теперк находнтсл в управлнемом 
коде. Поток осушествлнет переход в ндро Windows толбко при первом получении 
обвекта AutoResetEvent или при окончателвнои передаче его другому потоку. 
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В главе 29 бмли рассмотренм простеишие конструкции синхронизации потоков 
полБЗОвателБСКого режима и режима лдра. На их основе можно строитБ более 
сложнме конструкции синхронизации. Обмчно конструкции полвзователБСКого 
режима и режима идра комбинируготсл, а то что при зтом получаетсл, л назБшаго 
гибридними конструкцшми синхронизации потоков (hybrid thread synchronization 
constructs). При отсутствии конкуренции потоков гибриднБге конструкции 
дагот даже более вБгсокуго производителБностћ, чем простеишие конструкции 
полБЗОвателБСКого режима. В них также применнготсл простеишие конструкции 
режима лдра, что позволлет избежатв зацикливанин (пустои тратвг процессор- 
ного времени) при попБ1тке несколкких потоков одновременно получитв доступ 
к процессору. Так как в болвшинстве приложении потоки редко конкуриругот за 
доступ к конструкции, повБпнение производителБности способствует ускорениго 
работвг приложенгш. 

В зтои главе рассматриваготси Bonpocni созданин гибриднБгх конструкции на 
базе простеиших конструкции. В частности, вбг узнаете, какие именно гибриднБге 
конструкции поставллготсл вместе с FCL, познакомитесв с их поведением и получите 
представление о том, как правилвно с ними работатн. Упоминаготси и созданнБге 
лично много конструкции из библиотеки Wintellect Power Threading, которБге до- 
ступнБг длл загрузки (http://Wintellect.com/PowerThreading.aspx). 

Ближе к концу главБг л покажу, как минимизироватБ потребление ресурсов и по- 
ВБ1СИТБ ПрОИЗВОДИТеЛБНОСТБ с помогцбго безопаснБгх в отношении потоков классов 
коллекции из FCL, нвлигогцихсн алвтернативои гибриднБгм конструкцгшм. Ну 
и напоследок мбг обсудим асинхроннБге конструкции синхронизации, позволнгогцие 
синхронизироватБ доступ к ресурсу без блокировки потоков — а следователвно, 
сокрагцагогцие потребление ресурсов при одновременном улучшении масштаби- 
руемости. 


Простал гибриднал блокировка 

Начнем с демонстрации примера гибриднои блокировки в рамках синхронизации 
потоков: 

internal sealed class SimpleHybridLock : IDisposable { 

// Int32 исполБЗуетсл примитивнмми конструкцилми 
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// полвзователвского режима (Interlocked-MeTOflbi) 

private Int32 m_waiters = в; 

// AutoResetEvent - примитивнал конструкцил режима лдра 

private AutoResetEvent m_waiterLock = new AutoResetEvent(false); 

public void Enter() { 

// Поток хочет получитч блокировку 
if (Interlocked . Increment(ref m_waiters) == 1) 

return; // Блокировка свободна, конкуренции нет, возврашаем управление 

// Блокировка захвачена другим потоком (конкуренцил), 

// приходитсл ждатц. 

m_waiterLock.WaitOne(); // Значителцное снижение производителцности 
// Когда WaitOne возврашет управление, зтот поток блокируетсл 

} 

public void Leave() { 

// Зтот поток освобождает блокировку 
if (Interlocked.Decrement(ref m_waiters) == 0) 

return; // Другие потоки не заблокированн, возврашаем управление 

// Другие потоки заблокированм, пробуждаем один из них 
m_waiterLock.Set(); // Значителцное снижение производителцности 

} 

public void Dispose() { m_waiterLock.Dispose(); } 

} 

Класс SimpleHybridLock содержит два поли: одно типа Int32, управлие- 
мое примитивнмми конструкципми полвзователвского режима, и второе типа 
AutoResetEvent, нвлнкпцеесл примитивнои конструкциеи режима лдра. Чтобм 
добитБСи более вмсокои производителБности, при блокировании нужно пмтатБСп 
исполвзоватБ поле Int32 и по возможности не исполБЗОватБ поле AutoResetEvent. 
Поле AutoResetEvent создаетсн при конструировании обљекта SimpleHybridLock 
и нвлнетсн причинои значителћного сниженгш производителБности, особенно по 
сравненшо с полем Int32. Далее в зтои главе рассматриваетси егце одна гибриднан 
конструкцгш (AutoResetEventSlim), котораи не создает полн AutoResetEvent до 
возникновенгш конкуренции со сторонБ 1 потоков, одновременно пБ 1 таклцихсн до- 
битћси праванаблокирование. ЗакрБшакнции поле AutoResetEvent метод Dispose 
также значителБно снижает производителБностБ. 

Как ни заманчиво вбшллдит задача повБннешш производителБности при соз- 
дании и освобождении обвекта SimpleHybridLock, лучше сосредоточитБСи на его 
методах Enter и Leave, вБ13Б1ваемБ1хзавремн жизни обвектабессчетноеколичество 
раз. Даваите рассмотрим их подробно. 

ПервБ 1 ивмзвавшииметод Enter потокзаставлиетметод Interlocked . Incre- 
ment увеличитБ поле m_waiters на 1, сделав его значение равнБш единице. Поток 
обнаруживает, что прежде потоков, ожидаклцих права на данное блокирование, 
не 6бшо, позтому после вБ130ва метода Enter он возврагцает управление. ЗдесБ 
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важно то, что поток оченв бмстро блокируетси. Если теперБ понвитсн второи 
поток и вмзовет метод Enten, он увеличит значение полн m_waiters уже до двух 
и обнаружит присутствие уже запертого потока, позтому он блокируетси, вмзм- 
ваи метод WaitOne, исполБзугошии поле AutoResetEvent. Вмзов метода WaitOne 
заставит поток переити в идро Windows, и именно зта процедура приводит 
к значителБному снижениго производителвности. Однако зтот поток в лгобом 
случае должен прекратитБ свого работу, позтому тот факт, что полнаи остановка 
требует лишних временнБ 1 х затрат, не ивлнетсл слишком критичнБш. В итоге 
поток блокируетси и перестает впустуго расходоватБ процессорное времи из-за 
зацикливанин. Именно длн зтого и нужен продемонстрированнвш егце в главе 29 
метод Enten класса SimpleSpinLock. 

Теперв переидем к методу Leave. Его вбгоов потоком сопровождаетси вбгоовом 
метода Intenlocked . Decnement, ввшитагошего из полн m_waitens единицу. Ра- 
венство зтого полп нулго означает отсутствие заблокированнБ1х потоков внутри 
вБ130ва метода Enten, позтому поток, которвш ввговал метод Leave, может просто 
вернутв управление. И снова посмотрим, насколвко бкктро все зто происходит. 
Освобождение блокировки означает, что поток ввшитает единицу из поли Int32, 
вБшолннет бнштруго проверку условин и возврагцает управление! В то же времи, 
если вБ13Бшагогции метод Leave поток обнаруживает отличное от единицБ1 значение 
ilO.Hi m_waitens, он узнает о наличии конкуренции и о том, что, по краинеи мере, 
один заблокированнБш поток в идре уже имеетси. Поток, вБгзвшагогции метод Leave, 
должен разбудитБ один (и толбко один) из заблокированнБгх потоков. Длн зтого он 
вБгзБгвает метод Set обвекта AutoResetEvent. Даннаи операцгш ведет к снижениго 
производителБности, так как потоку приходитсп совершатк переходБг к ндру и обрат- 
но. К счастБго, подо6нбш переход осугцествллетсл толбко при наличии конкуренции. 
Разумеетсл, обвект AutoResetEvent гарантирует пробуждение толбко одного из 
заблокированнБгх потоков; все прочие заблокированнвге обвектом AutoResetEvent 
потоки останутси в таком состопнии, пока новбги незаблокированнБги поток не 
вБгзовет метод Leave. 

ПРИМЕЧАНИЕ 

В деиствителБности метод Leave может вмзватБ лкзбои поток в лкзбои момент 
времени, потому что метод Enter не сохранлет информацииз о том, какому по- 
току удалосБ успешно заперетБса. ДобавитБ длн зтого поле и управлчкидии код 
несложно, но зто увеличивает обвем памнти, необходимои длч самого обвекта 
блокированин, и снижает производителБностБ вБ 1 полненин методов Enter и Leave, 
ведБ им в резулБтате приходитсл работатБ с атим новмм полем. ^ предпочитак) 
иметБ бмстродеиствукшдее блокирование и корректно исполБзукпции его код. 
С информациеи подобного рода неумекзт работатБ ни собмтич, ни семафорн; зто 
могут делатБ толбко мБкзтексм. 
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Зацикливание, владение потоком 
и рекурсил 

Так как переходм в ндро значителБно снижагот производителћностБ, а потоки оста- 
готсл запертБгми оченБ короткое времн, обндуго производителвностБ приложенин 
можно ПОВБ1СИТБ, заставив поток перед переходом в режим ндра на некоторое времн 
зациклитБСн в полвзователБСКом режиме. Если в зто времн блокирование, которого 
ожидает поток, станет возможнбш, переход в режим лдра не понадобитсн. 

Кроме того, некоторБ 1 е вариантБ 1 блокировангш налагагот ограничение, в со- 
ответствие с которвш получитв право на блокировку может толбко поток, сни- 
магогции блокировку. Другие вариантБг блокировании допускагот рекурсивнБпг 
захват ресурса потоком. Именно такое поведение демонстрирует обвект Mutex'. 
С помогцбго нетривиалБнои логики можно реализоватБ гибридное блокирование, 
предполагагогцее одновременно зацикливание, владение потоком и рекурсиго. Вот 
пример подобного кода: 

internal sealed class AnotherHybridl_ock : IDisposable { 

// Int32 исполБзуетсл примитивом в полвзователвском режиме 
// (методм Interlocked) 
private Int32 m_waiters = 0 ; 

// AutoResetEvent - примитивнал конструкцил режима лдра 
private AutoResetEvent m_waiterLock = new AutoResetEvent(false); 

// Зто поле контролирует зацикливание с целш поднлтц производителцноств 
private Int32 m_spincount = 4000; // Произволцно вибранное значение 

// Зти полл указмвавт, какои поток и сколбко раз блокируетсл 
private Int32 m_owningThreadId = 0 , m_recursion = 0 ; 

public void Enter() { 

// Если визмватции поток уже захватил блокировку, увеличим рекурсивнни 

// счетчик на единицу и вернем управление 

Int32 threadld = Thread.CurrentThread.ManagedThreadld; 

if (threadld == m_owningThreadId) { m_recursion++; return; } 

// Вћ 1 зивак) 1 ции поток не захватил блокировку, питаемсл получитц ее 
SpinWait spinwait = new SpinWait( ); 

for (Int32 spinCount = 0; spinCount < m_spincount; spinCount++) { 

// Если блокирование возможно, зтот поток блокируетсл 
// Задаем некоторое состолние и возврацаем управление 
if (Interlocked.CompareExchange( 

ref m_waiters, 1 , 0) == 0) goto GotLock; 


1 При ожидании обЂекта Mutex поток не зацикливаетсн, потому что код зтого обвекта на- 
ходитсл в лдре. То естБ проверка состоннгш обвекта Mutex возможна толбко после перехода 
потока в ндро. 
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// Даем осталвнмм потокам шанс вшполнитнсл 
// в надежде на снитие блокировки 
spinwait . SpinOnce( ); 

} 

// Зацикливание завершено, а блокировка не сндта, 

// пштаемсл еце раз 

if (Interlocked . Increment(ref m_waiters) > 1) { 

// Осталцнше потоки заблокированш 

// и зтот также должен 6biTb заблокирован 

m_waiterLock.WaitOne(); // Ожидаем возможности блокированил; 

// производителвности падает 

// Проснувшиси, зтот поток получает право на блокирование 
// Задаем некоторое состолние и возврацаем управление 

} 

GotLock: 

// Когда поток блокируетсд, записшваем его идентификатор 
// и указшваем, что он получил право на блокирование впервше 
m_owningThreadId = threadld; m_recursion = 1; 

} 

public void Leave() { 

// Если BbBbiBaminnn поток не заперт, ошибка 
Int32 threadld = Thread.CurrentThread.ManagedThreadld; 
if (threadld != m_owningThreadId) 
throw new SynchronizationLockException( 

"Lock not owned by calling thread"); 

// Уменишаем на единицу рекурсивнши счетчик. Если поток все еше 
// заперт, просто возврашаем управление 
if (--m_recursion > 0) return; 

m_owningThreadId = 0; // Запертшх потоков болнше нет 

// Если нет других заблокированншх потоков, возврацаем управление 
if (Interlocked.Decrement(ref m_waiters) == 0) 
return; 

// ОсталБнше потоки заблокированш, пробуждаем один из них 
m_waiterLock.Set(); // Значителиное падение производителнности 

} 

public void Dispose() { m_waiterLock.Dispose(); } 

} 

Как видите, ocnaiueinie кода блокированин дополнителБнои логикои увеличи- 
вает количество имеклцихси полеи, а значит, и потребление памнти. Код, которми 
должен вшполнитбси, становитсл сложнее, что также снижает производителћностБ 
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блокировашш. В главе 29 сравниваласБ производителБностБ конструкции, где 
увеличивалосБ на единицу значение типа Int32 без блокировангш, а также при- 
митивнои конструкции полБЗОвателвского режима и конструкции режима лдра. 
И воспроизведу здесв резулБтатБ1 теста, добавив к ним резулвтатБ1 исполБЗОванин 
классов SimpleHybnidlock и AnotherHybridLock. Вот они от самого бвштрого 
к самому медленному: 


Incrementing х: 8 
Incrementing х in М: 69 
Incrementing х in SpinLock: 164 
Incrementing х in SimpleHybridLock: 164 
Incrementing х in AnotherHybridLock: 230 

Incrementing х in Simplel/JaitLock: 8,854 


Самни бмстрми 
Медленнее ~9 раз 
Медленнее ~21 раз 

Медленнее ~21 раз (аналогично SpinLock) 
Медленнее ~29 раз (из-за владениа/ 
рекурсии) 

Медленнее ~1107 раз 


Стоит заметитв, что блокировка AnotherHybridLock отнимает в два раза болвше 
времени, чем SimpleHybrid Lock. Зто обусловлено дополнителвнои логикои и про- 
веркои ошибок, необходимои длл управленгш владением потоком и рекурсиеи. 
Как видите, на производителвности отрицателБно сказБшаетсл лгобаи логика, до- 
бавлиеман в код блокировашш. 


Гибриднме конструкции в FCL 

В FCL сугцествует множество гибриднБ 1 х конструкции, исполБзугогцих изогцреннуго 
логику, которан должна удержатк потоки в полвзователБСКом режиме, повБ1шал 
производителБностБ приложенгш. В некоторБ1х гибриднБ1х конструкцгшх воз- 
никновешш конкуренции между потоками обрагценгш к конструкцгшм режима 
лдра также не происходит. В резулвтате, если конкуренции так и не возникает, 
приложениго не приходитсл сталкиватвсл с падением производителБности и не- 
о6ходимостбго вБвделлтБ памлтБ дли обвекта. Некоторкге конструкции поддержи- 
вагот обвект CancellationToken (он рассматривалсн в главе 27), а значит, поток 
получает возможностб принудителБно разблокироватБ другие потоки, которБ1е 
могут находитБСл в режиме ожиданин. В зтом разделе mbi рассмотрим различнвге 
ТИПБ1 ГибрИДНБ1Х конструкции. 

Классм ManualResetEventSlim и SemaphoreSlim 

Первкге две гибриднвге конструкции — зто классБ 1 System . Threading . ManualReset- 
EventSlim и System. Threading. SemaphoreSlim 1 . Они функциониругот точно так же, 
как их аналоги режима ндра, отличансБ толбко зацикливанием в полвзователБСКом 


1 Хотл класса AutoResetEventSlim не сушествует, во многих ситуацилх можно обоитисв 
конструированием обвекта SemaphoreSlim с параметром maxCount равнћгм единице. 
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режиме, а также тем, что они не создагот конструкции режима лдра до возникно- 
венин конкуренции. Их методм Wait позволнгот передатБ информациго о времени 
ожиданин и обвект CancellationToken. Вот как вмглддлт даннме классм (некоторме 
перегруженнме версии методов не показанм): 

public class ManualResetEventSlim : IDisposable { 

public ManualResetEventSlim(Boolean initialState, Int32 spinCount); 

public void Dispose(); 

public void Reset(); 

public void Set(); 

public Boolean Wait( 

Int32 millisecondsTimeout, CancellationToken cancellationToken); 

public Boolean IsSet { get; } 
public Int32 SpinCount { get; } 
public WaitHandle WaitHandle { get; } 

} 

public class SemaphoneSlim : IDisposable { 

public SemaphoneSlim(Int32 initialCount, Int32 maxCount); 
public void Dispose(); 

public Int32 Release(Int32 neleaseCount); 
public Boolean Wait( 

Int32 millisecondsTimeout, CancellationToken cancellationToken); 

// Специалвнми метод длл исполцзованин с async и await (см. главу 28) 
public Task<Boolean> WaitAsync(Int32 millisecondsTimeout , 

CancellationToken cancellationToken); 

public Int32 CunnentCount { get; } 

public WaitHandle AvailableWaitHandle { get; } 

} 


Класс Monitor и блоки синхронизации 

Вероитно, самои популирнои из гибриднмх конструкции синхронизации потоков 
нвлнетсл класс Monitor, обеспечивагогции взаимоисклгочагогцее блокирование с за- 
цикливанием, владением потоком и рекурсиеи. Даннаи конструкцин исполБзуетси 
чагце других потому, что нвлнетсл однои из самћгх старБгх, длн ее поддержки в C# 
сугцествует встроенное клгочевое слово, с неи по умолчаниго умеет работатв JIT- 
компилнтор, а CLR полБзуетсн его от имени приложенгш. Однако, как вбг скоро 
убедитесБ, работатБ с неи непросто, а получитБ некорректнБш код оченк легко. 
Сначала мбг рассмотрим саму конструкциго, а потом отделнно остановимси на воз- 
можнбгх проблемах и способах их обхода. 

С каждБгм обвектом в куче может 6бгтб свнзана структура даннвгх, назБгваемаи 
блоком синхронизации (sync block). Зтот блок содержит полн, похожие на полн 
ранее упоминавшегоси в зтои главе класса AnotherHybridLock. Точнее, еств поле 
длн обвекта ндра, идентификатора потока-владелБца, счетчика рекурсии и счетчика 
ожидагогцих потоков. Класс Monitor нвлнетсн статическим, и его методвг принимагот 
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ссмлки на лгобои о6ђскт кучи. Управление полнми зти методм осундествлнгот в бло- 
ке синхронизации заданного обвекта. Вот как вмгллдлт чагце всего исполБзуемме 
методм класса Monitor: 

public static class Monitor { 

public static void Enter(Object obj); 
public static void Exit(Object obj); 

// Можно также указати времп блокированип (требуетсп редко): 

public static Boolean TryEnter(Object obj^ Int32 millisecondsTimeout); 

// Аргумент lockTaken будет рассмотрен позднее 

public static void Enter(Object obj^ ref Boolean lockTaken); 

public static void TryEnter( 

Object obj, Int32 millisecondsTimeout, ref Boolean lockTaken); 

} 

Очевидно, что привнзка блока синхронизации к каждому обвекту в куче чв- 
лиетсл достаточно расточителћнои, особенно если учестБ тот факт, что болБшин- 
ство обвектов никогда не полБзуготси зтим блоком. Что 6 б 1 снизитб потребление 
памлти, разработчики CLR применили более зффективнБпт вариант реализации 
описаннои функционалБности. Во времн инициализации CLR вБтделнетсн массив 
блоков синхронизации. Как уже не раз упоминалосв в зтои книге, при создании 
обвекта в куче с ним свнзвшаготсл два дополнителБНБ 1 х служебнБ 1 х полн. Первое 
поле — указателв на обЂект-тип — содержит адрес зтого обнекта в памнти. Вто- 
рое поле содержит индекс блока синхронизации (sync block index), то еств индекс 
в массиве таких блоков. 

В момент конструировангш обвекта зтому индексу присваиваетсл значение — 1, 
что означает отсутствие ссбшок на блок синхронизации. Затем при вБИОве метода 
Monitor . Enter CLR обнаруживает в массиве свободнвш блок синхронизации и при- 
сваивает ссвшку на него обЂекту. То естБ привизка обвекта к блоку синхронизации 
происходит «на лету». Метод Exit провериет наличие потоков, ожидагогцих блока 
синхронизации. Если таких потоков не обнаруживаетсл, метод возврагцает индексу 
значение -1, означагогцее, что блоки синхронизации свободнвг и могут 6 бгтб свнзанБг 
с какими-нибудБ другими обЂектами. 

Рисунок 30.1 демонстрирует свнзб между обБектами кучи, их индексами блоков 
синхронизации и злементами массива блоков синхронизации в CLR. Указателв на 
обЂект-тип обЂектов А, В и С ссвшаетсн на тип Т. Зто говорит о принадлежности 
всех трех обвектов к одному и тому же типу. Как обсуждалосв в главе 4, обвект- 
тип также находитсл в куче и подобно всем осталвнБгм обЂектам обладает двумл 
служебнБши членами: индексом блока синхронизации и указателем на обБект-тип. 
То естБ блок синхронизацгш можно свизатБ с обЂектом-типом, а ссвшку на зтот 
обЂект можно передатБ методам класса Monitor. Кстати, массив блоков синхро- 
низации при необходимости может увеличитв количество блоков, позтому не 
стоит беспокоитБСи, что при одновременнои синхронизацгш несколвких обЂектов 
блоков не хватит. 
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Рис. 30.1. Индекс блоков синхронизации обБектов в куче (вклкзчан o6beKTbi-THnbi) 
может ccbmaTbc^ на записи в массиве блоков синхронизации CLR 


Следукиции код демонстрирует предполагаемми исходнми вариант исполбзо- 
ванин класса Monitor: 

internal sealed class Transaction { 
private DateTime m_timeOfLastTransj 

public void PerformTransaction() { 

Monitor.Enter(this); 

// Зтот код имеет аксклтзивнми доступ к даннмм... 
m_timeOfLastTrans = DateTime.Now; 

Monitor.Exit(this); 

} 

public DateTime LastTransaction { 
get { 

Monitor.Enter(this); 

// Зтот код имеет совместнни доступ к даннмм... 

DateTime temp = m_timeOfLastTrans; 

Monitor . Exit(this) ; 
return temp; 

} 

} 


} 
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На первми взглнд все вв 1 глндит достаточно просто, но зто не так. Проблема в том, 
что индекс блока синхронизации каждого обвекта неивно находитсн в открмтом 
доступе. И вот как зто пронвлнетсл: 

public static void SomeMethod() { 
var t = new Transaction(); 

Monitor.Enter(t); // Зтот поток получает открмтук) блокировку обвекта 

// Заставллем поток пула внвести времл LastTransaction 
// ПРИМЕЧАНИЕ. Поток пула заблокирован до внзова 
// методом SomeMethod метода Monitor . Exit ! 

ThreadPool.QueueUserWorkItem(o => Console.WriteLine(t.LastTransaction)); 

// Здеси внполнлетсл какои-то код... 

Monitor.Exit(t); 

} 

В зтом коде поток, вмполннгогции метод SomeMethod, вмзмвает метод Monitor . 
Enten, получаи открмтуго блокировку обвекта Transaction. Когда поток пула за- 
прашивает своиство LastTransaction, зто своиство также вмзмвает метод Monitor . 
Enter, чтобм получитБ право на то же самое блокирование. В резулкгате поток пула 
оказмваетсл заблокированнмм, пока поток, вмполнигогции метод SomeMethod, не 
вмзовет метод Monitor . Exit. При помогци отладчика можно определитБ, что поток 
пула заблокирован внутри своиства LastTransaction, но узнатБ, какои егце поток 
заблокирован, оченв сложно. Длл зтого нужно поинтб, какои именно код привел 
к получениго блокировки. Но даже если bbi зто узнаете, вполне может оказатвси, 
что зтот код окажетсл недоступнБш длл редактированин, а значит, bbi не сможете 
устранитБ проблему. Именно позтому н предлагаго полБЗОватБСн толбко закркгтБши 
блокировками. Вот каким образом следует исправитв класс Т ransaction: 

internal sealed class Transaction { 

private readonly Object m_lock = new Object(); // Tenepb блокирование 

// в рамках каждои транзакции 3AKPblT0 

private DateTime m_timeOfLastTrans; 

public void PerformTransaction() { 

Monitor. Enter(m_lock); // Вход в закрмтук) блокировку 
// Зтот код имеет зксклтзивнми доступ к даннмм... 
m_timeOfLastTrans = DateTime.Now; 

Monitor . Exit(m_lock); // Внход из закрмтои блокировки 

} 

public DateTime LastTransaction { 
get { 

Monitor. Enter(m_lock); // Вход в закрш-ук) блокировку 
// Зтот код имеет монополбнми доступ к даннум... 

DateTime temp = m_timeOfLastTrans; 

Monitor.Exit(m_lock); // Завершаем закрштое блокирование 
return temp; 

} 

} 

} 
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Если бм членм класса Transaction бмли статическими, длн их безопасности 
в отношении потоков достаточно бмло бм сделатБ статическим поле m_lock. 

Однако и думакз, вм уже поннли из предшествугоших обсуждении, что класс 
Monitor не должен 6 б 1 тб реализован как статическии; его следует реализоватБ, как 
и все прочие конструкции, в виде класса, допускагогцего создание зкземплнров 
и вб130в зкземплнрнБ 1 х методов. Также реализацгш класса Monitor как статического 
создаст рнд дополнителБНБгх проблем: 

□ Если тип обБекта-представителл нвлнетсл производнБш от System.Marshal- 
ByRefObject, на такои обвект может ссБшатБСн переменнан (зта тема рассма- 
триваласБ в главе 22). При передаче методам класса Monitor ссбшки на такои 
представителБ блокируетси представителБ, а не представлиемБги им обвект. 

□ Если поток вБ13Б1вает метод Monitor . Enter и передает в него ссбшку на обвект- 
тип, загруженшли неитралБно по отношениго к домену (о том, как зто сделатБ, 
мб 1 говорили в главе 22 ), поток блокирует зтот тип во всех доменах процесса. 
Зто известнан недоработка CLR, нарушагогцан декларируемуго изолированностБ 
доменов. ИсправитБ ее без потери производителБности сложно, позтому никто 
зтим не занимаетси. ПолБЗОвателлм просто рекомендугот никогда не передаватБ 
ссБшку на обвект-тип в методБг класса Monitor. 

□ Так как строки допускагот интернирование (зто обсуждалосв в главе 14), два 
разнБгх фрагмента кода могут ошибочно сослатБСн на один и тот же обвект String 
в памлти. При передаче ссбшки на зтот обвект в методБг типа Monitor вБшолнение 
зтих двух фрагментов кода будет непреднамеренно синхронизироватБСн. 

□ При передаче строки через границу домена CLR не создает ее копиго; ссБшка на 
строку просто передаетсл в другои домен. Зто поввгшает производителБностБ, 
и в теоргш все должно 6 бгтб в поридке, так как обвектБг типа String неизменнБг. 
Но с ними, как и с лго 6 бгми другими обвектами, свнзан индекс блока синхрони- 
зации, которБпг может изменнтБСн. Таким образом, потоки в различнБ 1 х доменах 
начинагот синхронизироватБСн друг с другом. Зто егце одна недоработка CLR, 
свнзаннан с недостаточнои изолированностБго доменов. Позтому полБЗОвателнм 
рекомендуетсл никогда не передаватБ ссбшок на о 6 бсктбг типа String методам 
класса Monitor. 

□ Так как методБг класса Monitor пргшимагот параметрБ 1 типа Object, передача 
им значимого типа приводит к его упаковке. В резулБтате поток блокирует 
упакованнБпг обвект. При каждом вБгзове метода Monitor . Enter блокируетсн 
другои обвект, и синхронизацгш потоков вообгце отсутствует. 

□ Применение к методу атрибута [MethodImpl(MethodImplOptions .Synchro- 
nized) ] заставлиет JIT -компгшнтор окружитБ машиннБш код метода вБ130вами 
Monitor . Enter и Monitor . Exit. Если метод ивлнетсл зкземплнрнБш, зтиммето- 
дам передаетсл this, что приводит к установлениго ненвно открБ1тои блокировки. 
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В случае статического метода зтим двум методам передаетсл ссмлка на обвект- 
тип, что приводит к потенциалБнои блокировке неитралБного по отношенгпо 
к домену типа. Позтому исполБЗОватБ даннми атрибут не рекомендуетсл. 

□ При вмзове конструктора типов (он обсуждалсл в главе 8) CLR блокирует длн 
типа обвект-тип, гарантирун, что всего один поток примет участие в инициа- 
лизации данного обвекта и его статических полеи. И снова загрузка зтого типа 
неитралБно по отношеншо к домену создает проблемм. К примеру, если код 
конструктора типа воидет в бесконечнми цикл, тип станет непригоднмм длл 
исполт>зовашш всеми доменами в процессе. В данном случае рекомендуетсл по 
возможности избегатБ конструкторов типа или хотл 6bi делатБ их как можно 
более короткими и простБши. 

К сожаленшо, далнше все становитси толбко хуже. Так как разработчики при- 
ВБ 1 КЛИ в одном и том же методе устанавливатв блокировку, что-то делатв, а затем 
сниматБ блокировку, в C# понвилсн упрогценнБш синтаксис в виде клгочевого слова 
lock. Рассмотрим следугогции метод: 

private void SomeMethod() { 
lock (this) { 

// Зтот код имеет аксклтзивнми доступ к даннмм... 

} 

} 

Приведеннвш фрагмент зквивалентен следугогцему: 

private void SomeMethod() { 

Boolean lockTaken = false; 
try { 

// 

Monitor.Enter(this, ref lockTaken); 

// Зтот код имеет монополинии доступ к даннмм... 

} 

finally { 

if (lockTaken) Monitor . Exit(this) ; 

} 

} 

Перван проблема в данном случае состоит в приннтом разработчиками C# реше- 
нгш, что метод Monitor . Exit лучше вБгзвгватБ в блоке finally. Они считали, что зто 
гарантирует сннтие блокировки вне зависимости от происходнгцего в блоке try. Од- 
нако ничего хорошего в зтом нет. Если в блоке try в процессе измененгш состоннгш 
возникнет исклгочение, состонние окажетсл поврежденнБш. И снитие блокировки 
в блоке f inally приведет к тому, что с поврежденнБш состоннием начнет работатн 
другои поток. Лучше позволитб приложениго зависнутБ, чем оставитБ его работатБ 
с поврежденнБши даннБгми и потенциалБНБши брешами в загците. Кроме того, 
вход в блок t ry и вбгход из блока снижает производителБностБ метода. НекоторБге 
Ј1Т-компилнторБ1 не поддерживагот подстановку длн методов, в которвгх имеготси 
блоки try, что егце болвше снижает производителБностБ. В итоге мбг получаем 
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более медленнми код, к тому же допускакнции доступ потоков к поврежденному 
состомшпо 1 . Позтому н краине не рекомендуго вам полБЗОватБСн инструкциеи lock. 

Теперн переидем к переменнои lockTaken типа Boolean и к проблеме, которуго 
призвана решитв зта переменнан. Предположим, поток вошел в блок try и 6бш пре- 
рван до ввгоова метода Monitor . Enter (прервшание потоков обсуждалосв в главе 22). 
После зтого ввгоБшаетсл блок finally, но его код не должен сниматБ блокировку. 
В зтом нам поможет переменнан lockTaken. Еи присваиваетси началвное значение 
false, означагогцее, что блокировка егце не установлена. Если ввгованнБш метод 
Monitor . Enter успешно получает блокировку, переменнои lockTaken присваиваетсн 
значение true. Блок finally по значениго зтои переменнои определлет, нужно ли 
ввгоБшатБ метод Monitor . Exit. Кстати, структура SpinLock также поддерживает 
паттерн с переменнои lockTaken. 

Класс ReaderWriterLockSlim 

Часто потоки просто читагот некие даннвге. Если такие даннкге загцигценБг взаи- 
моисклгочагогцеи блокировкои (например, SimpleSpinLock, SimpleWaitLock, 
SimpleHybridLock, AnotherHybridLock, Mutex илгг Monitor), то пргг попвгтке одно- 
временного доступа несколвких потоков работу продолжит толбко один из нггх, 
а осталБНБге блокируготсн, что значггтелБно ухудшает масштабируемостБ и снижает 
производителБностБ вашего приложенгш. Впрочем, в случае доступа в режггме 
толбко длл чтенгш необходимостБ в блокировке отпадает, и потокгг получагот 
одновременнвги доступ к данннгм. А вот потоку, которвш хочет внести в даннвге 
измененгш, требуетсл монополбнбги доступ. Конструкцгш ReaderWriterLockSlim 
содержит логику, позволнгогцуго решитв даннуго проблему. Управление потоками 
осугцествлиетсл следугогцим образом: 

□ Еслгг одггн поток осугцествлнет запггсв даннБгх, все осталБНБге потокгг, требугогцие 
доступа, блокируготсн. 

□ Еслгг один поток читает даннкге, все осталвнБге потокгг, требугогцие доступа, про- 
должагот работу, блокируготсл толбко потоки, ожидагогцие доступа на записБ. 

□ После завершенгш работвг потока, осугцествлчвшего запггсв даннБгх, разблокггру- 
етсл либо один поток, ожидагогцгш доступ на записБ, либо все потоки, ожидаго- 
гцие доступ на чтенгге. При отсутствии заблокированнвгх потоков блокировку 
получает следугогции поток чтенгш или записи, которому зто потребуетсл. 

□ После завершенггн всех потоков, осугцествлнвших чтенгге даннвгх, разблокггруетсн 
поток, ожидагогцгггг разрешенггн на записБ. Пргг отсутствгггг заблокированнвгх 
потоков блокггровку получит следугогцгги поток чтенггч или записи, которому 
зто потребуетсл. 


1 Кстати говорн, блокировку можно безопасно снлтв в блоке finally, если код блока try 
толбко читает состолние, не пвгталсБ его изменнтв (впрочем, зто также приводит к сниженшо 
производителвности). 
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Вот как вшгллдит даннми класс (некоторме перегруженнме версии методов не 
показанм): 

public class ReaderWriterLockSlim : IDisposable { 

public ReaderWriterLockSlim(LockRecursionPolicy recursionPolicy); 
public void Dispose(); 

public void EnterReadLock(); 

public Boolean TryEnterReadLock(Int32 millisecondsTimeout); 
public void ExitReadLock(); 

public void EnterWriteLock(); 

public Boolean TryEnterWriteLock(Int32 millisecondsTimeout); 
public void ExitWriteLock(); 

// Болвшинство приложении никогда не обрашаттсл к атим своиствам 

public Boolean IsReadLockHeld { get; } 

public Boolean IsWriteLockHeld { get; } 

public Int32 CurrentReadCount { get; } 

public Int32 RecursiveReadCount { get; } 

public Int32 RecursiveWriteCount { get; } 

public Int32 WaitingReadCount { get; } 

public Int32 WaitingWriteCount { get; } 

public LockRecursionPolicy RecursionPolicy { get; } 

// He показанм членмЈ свлзаннше с переходом от чтенил к записи 

} 

Следукнции код демонстрирует применение даннои конструкции: 

internal sealed class Transaction : IDisposable { 
private readonly ReaderWriterLockSlim m_lock = 

new ReaderWriterLockSlim(LockRecursionPolicy.NoRecursion); 
private DateTime m_timeOfLastTrans; 

public void PerformTransaction() { 
m_lock.EnterWriteLock(); 

// Зтот код имеет монополвнни доступ к даннмм... 
m_timeOfLastTrans = DateTime.Now; 
m_lock.ExitWriteLock( ) ; 

} 

public DateTime LastTransaction { 
get { 

m_lock.EnterReadLock(); 

// Зтот код имеет совместнши доступ к данншм... 

DateTime temp = m_timeOfLastTrans; 
m_lock.ExitReadLock( ) ; 
return temp; 

} 

} 

public void Dispose() { m_lock.Dispose(); } 

} 
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С зтои конструкциеи свизан рнд концепции, заслуживаготцих отделБного упо- 
минанин. Во-первмх, конструктору ReaderWriterLockSlim можно передатБ флаг 
LockRecurionsPolicy, определеннБп! следуклцим образом: 

public enum LockRecursionPolicy { NoRecursion, SupportsRecursion } 

Флаг SupportsRecursion наделнет код блокировангш механизмом владенгш по- 
током и рекурсивнБш поведением. Как уже упоминалосБ в зтои главе, зти режимБ 1 
негативно влиигот на производителБностБ блокировании, так что н рекомендуго 
всегда передаватБ конструктору флаг LockRecursionPolicy.NoRecursion (как 
зто сделано в моем примере). Поддержка режимов владенин потоком и рекурсии 
длн блокировашш на чтение-записв нвллетсн краине дорогим удоволвствием, ведв 
при блокировании нужно отслеживатв все блокируемБ 1 е потоки, занимагогциеси 
чтением даннБ1х, и поддерживатБ длл каждого из них отделБНБш счетчик рекурсии. 
На самом деле дли управленин Bceii зтои информациеи в безопасном в отношении 
потоков режиме конструкцин ReaderWriterLockSlim внутренне исполвзует взаи- 
моисклгочагогцее блокирование с зацикливанием! И и не шучу. 

Класс ReaderWriterLockSlim содержит дополнителБнвге методБ 1 (ранее они не 
демонстрировалисБ), позволигогцие читагогцему потоку превратитвсн в поток за- 
писБшагогции. Затем возможен обратнвш переход. В основе такого подхода лежит 
идел, что в процессе чтенин даннвгх потоком может возникнутБ необходимостБ 
их редактировангш. Поддержка данного поведенгш снижает производителвностБ 
блокировангш. Ну а н так вообгце считаго его бесполезнвш. Дело в том, что поток не 
может просто так превратитвсн из читагогцего в пишугции. Перед тем как он получит 
позволение на подобное преобразование, все осталБнвге читагогцие потоки должнбг 
покинутБ код блокировангш. Зто то же самое, что поток чтенгш, освобождагогции 
блокировку и тут же получагогцгш ее длл записи. 

ПРИМЕЧАНИЕ 

В FCLTaioKe присутствует конструкциа ReadertA/riterLock, поавившалса еш,е в Microsoft 
.NET Framework 1.0. Она бнла настолБко проблемнои, что в версикз 3.5 разра- 
ботчики Microsoft ввели конструкцикз ReaderWriterLockSlim. МенчтБ конструкцикз 
ReaderWriterLockoHH не стали, чтобБ 1 не потерчтБсовместимости с исполБзукнцими 
ее приложенинми. Даннал конструкцил работает краине медленно даже в отсутствии 
конкуренции потоков. Она не позволлет отказатБСл от владенич потоком и рекурсив- 
ного поведенил, еиде силБнее замедпчкнцих блокирование. Потоки чтенил имекзт 
в зтои конструкции приоритет перед потоками записи, что может привести к про- 
блемам типа «отказ в обслуживании». 

Класс OneManyLock 

И создал собственнуго конструкциго чтенгш-записи, работагогцуго бвгстрее, чем 
встроеннми в FCL класс Reader^riterLockSlim 1 . Зта конструкцгш назвгваетси 


1 Код в фаиле Ch30-l-HybridThreadSync.cs нвллетсл частвго сопроводителвного кода 
к даннои книге. Вн можете загрузитв его с саита http://Wintellect.com/Books. 
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OneManyLock, так как она предоставлнет доступ либо одному пишутцему потоку, либо 
несколБКим читатошим. Даннми класс вмглндит примерно следугогцим образом: 

public sealed class OneManyLock : IDisposable { 
public OneManyLock(); 
public void Dispose(); 

public void Enter(Boolean exclusive); 
public void Leave(); 

} 

Tenepb посмотрим, как зто работает. Класс содержит поле типа Int32, предна- 
значенное длн храненин состоннин блокировангш, обвект Semaphore, блокиругогции 
читагогцие потоки, и обвект AutoResetEvent, блокиругогции пишугцие потоки. Поле 
записи состоингш содержит в себе пнтб вложеннмх полеи. 

□ Четмре бита представлнгот состонние блокировки. Значение 0 означает F ree (до- 
ступно), 1 — OwnedByWriter (заннто записмвагогцим потоком), 2 — OwnedByReaders 
(заннто читагогцими потоками), 3 — OwnedByReadersAndWriterPending (заннто 
записмвагогцим и читагогцими потоками) и 4 — ReservedForWriter (зарезерви- 
ровано д./ш записмвагогцего потока). Другие значенгш не исполБзуготсл. 

□ ДвадцатБ битов (число от 0 до 1048575) представлнгот количество потоков чтенгш 
(RR), допустиммх длн блокировки. 

□ ДвадцатБ битов представлигот количество потоков чтенгш (RW), ожидагогцих 
полученгш блокировки. Зти потоки удерживает обвект AutoResetEvent. 

□ ДвадцатБ битов представлигот количество потоков записи (WW), ожидагогцих 
полученгш блокировки. Зти потоки удерживает обвект Semaphore. 

ТеперБ, когда всн информацгш о блокировании сконцентрирована в одном поле 
типа Int64, н могу управлитБ зтим полем при помогци методов класса Interlocked. 
В резулБтате блокирование вБшолннетсн очснб бБгстро и приводит к блокированиго 
потока толбко при конкуренции потоков. 

Вот что происходит при входе потока в код блокировангш совместного досту- 
па: 

□ Если блокирование возможно, присваиваем состонниго значение OwnedByReaders, 
вБшолннем RR = 1, возврагцаем управление. 

□ Если состонние блокировангш имеет значение OwnedByReaders (заннто потоком 
чтенгш), вБшолннем RR++, возврагцаем управление. 

□ В противном случае ввшолннем RW++, блокируем поток чтенгш. Когда поток 
проснетсл, проходим цикл и делаем вторуго попБгтку. 

Вот что происходит при вБгходе потока из кода блокировки совместного до- 
ступа: 

□ ВБгполннем RR - -. 
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□ Если RR > 0, возврашаем управление. 

□ Если1л11л1 > 0, npiiCBaiiBaeMCOCTOHHino3Ha4eHiieReservedForWniter(3ape3epBiipo- 
вано длн потока записи), вмполнием WW - освобождаем один заблокированнми 
поток записи, возврандаем управление. 

□ Если RW = 0 и WW = 0, присваиваем состоиншо значение Free (свободно), воз- 
врашаем управление. 

Вот что происходит при входе потока в код блокировки с монополбнмм до- 
ступом: 

□ Если блокирование возможно, присваиваем состонншо значение OwnedByWniter 
(занито потоком записи), возврандаем управление. 

□ Если состоиние блокировки равно ReservedForWriter (зарезервировано длл 
потока записи), присваиваем состоипи io значение OwnedByWriter (запито по- 
током записи), возвратцаем управление. 

□ Если состонние блокировки равно OwnedByWriter (занито потоком записи), 
вмполннем WW++, блокируем поток записи. Когда поток проснетсл, проходим 
цикл и делаем вторуго попмтку. 

□ В противном случае присваиваем состолниго значение OwnedByReaders- 
AndWriterPending (ожидание потоков чтенил и записи), вмполннем WW++, бло- 
кируем поток записи. Когда поток проснетсл, проходим цикл и делаем вторуго 
попмтку. 

Вот что происходит при вмходе из блокировки потока с монополбнмм доступом: 

□ Если WW = 0 и RW = 0, присваиваем состонниго значение Free (свободно), воз- 
врагцаем управление. 

□ EcnnWW > 0, npiiCBaiiBaeMCOCTOHHino3Ha4eHiieReservedForWriter(3ape3epBiipo- 
вано длн потока записи), вмполнием WW - -, освобождаем один заблокированнми 
поток записи, возврагцаем управление. 

□ Если WW = 0 и RW > 0, присваиваем состонниго значение Free (свободно), вм- 
полннем RW = 0, пробуждаем все заблокированнме потоки чтенгш, возврагцаем 
управление. 

Предположим, что у нас один запертми поток осугцествлнет чтение, а другои 
ждет освобожденгш блокировки, чтобм осугцествитБ записм Записмвагогции поток 
сначала проверит, свободна ли блокировка, и так как резулглат будет отрицателБ- 
нб 1 м, начнет готовитбсн к следугогцеи проверке. Но в зтот момент читагогции поток 
может покинутв код блокировки, и обнаружив, что значенгш RR и WW равнБ 1 0, поток 
присвоит состонниго блокировки значение F ree. Однако проблема в том, что поток 
записи уже закончил проверку состопнгш и продолжил ввшолнение. Фактически 
поток чтенгш «за спинои» потока записи меннет то состонние, к которому послед- 
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нии пмтаетсн получити доступ. Длн корректного блокировангш нужно разобратћсн 
с даннои проблемои. 

Дли зтого все манипулиции с битами вмполннготсл с применением приемов, 
описаннмх в разделе «Универсалг>нми Interlocked-naTTepH» главм 29. Если пом- 
ните, даннми паттерн преврагцает лгобуго операциго в безопаснуго в отношении 
потоков и атомарнуго. Именно зто обеспечивает бмстрое блокирование. Сравнив 
производителБностБ моего класса OneManyLock и классов ReaderWritenLockSlim 
и ReaderWriterLock из FCL, м получил следугогции резулћтат: 

Прирашение х в OneManyLock: 330 — максималвно б|>к'тро. 

Прирашение х в ReaderWriterLockSlim: 554 — примерно в 1,7 раза медленнеи. 

Прирашение х в ReaderWriterLock: 984 — примерно в 3 раза медленнеи. 

Разумеетсл, производителвностБ блокировангш на чтение-записБ немного ниже 
из-за того, что логика здеск более насБггцена, чем во взаимоисклгочагогцем блоки- 
ровании. Но стоит помнитб также и о том, что блокирование на чтение-записБ до- 
пускает одновременное исполнение несколвких читагогцих потоков. 

В завершение зтого раздела н в очереднои раз упомину мого библиотеку Power 
Threading librarv (ее можно загрузитв бесплатно по адресу http://Wintellect.com/ 
PowerThreading.aspx). Она содержит немного другуго версиго зтои блокировки, ко- 
тораи назБшаетсл OneManyResourceLock. Зтоти другие вариантБгблокировангшиз 
моеи библиотеки предлагагот множество дополнителвнБгх возможностеи, например 
распознавание взаимнои блокировки (deadlocks), вклгочение режимов владенгш бло- 
кированием и рекурсии (за что придетсл платитв снижением производителБности), 
унифицированнан программнаи моделв всех блокировок и средства наблгоденгш за 
поведением блокировок в процессе ввшолненгш. При наблгодении за поведением 
можно узнатв максималБное времн ожидангш полученгш блокировки потоком, 
а также максималвное и минималвное времн удержангш блокировки. 

Класс CountdovvnEvent 

Следугогцан конструкцгш назБгваетси System . Threading . CountdownEvent. Она по- 
строена на основе обвекта ManualResetEventSlim и блокирует поток до достиженгш 
внутренним счетчиком значенгш 0. Поведение зтои конструкции диаметралвно 
противоположно поведениго семафора (блокиругогцего потоки, пока значение 
счетчика равно 0). Вот как вбггллдит даннБш класс (некоторБге перегруженнБге 
версии методов не показанвг): 

public class CountdownEvent : IDisposable { 
public CountdownEvent(Int32 initialCount); 
public void Dispose(); 
public void Reset(Int32 count); 

public void AddCount(Int32 signalCount); 

public Boolean TryAddCount(Int32 signalCount); 


// Присваиваем CurrentCount 
// значение count 
// Увеличение CurrentCount 
// на signalCount 
// Увеличение CurrentCount 
// на signalCount 


продолжение & 
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public Boolean Signal(Int32 signalCount) ; // Уменвшение CumentCount 

// на signameCount 

public Boolean Wait( 

Int32 millisecondsTimeout, CancellationToken cancellationToken); 
public Int32 CunnentCount { get; } 

public Boolean IsSet { get; } // tnue, если 

// CunnentCount равно 0 

public WaitHandle WaitHandle { get; } 

} 


Достигнутое параметром CurrentCount класса CountdownEvent нулевое значение 
уже не может 6 бггб изменено. Если параметр CurrentCount равен 0, метод AddCount 
генерирует исклкзчение InvalidOperationException, а метод Т ryAddCount просто 
возврагцает значение false. 

Класс Barrier 

Конструкцин System . Threading . Barrier бвша создана длн решенил достаточно 
редко возникакчцеи проблемБ 1 , так что врлд ли вам когда-нибудв придетсл eio 
полБЗОватБСл. Она управлнет группами параллелвно вбшолннкнцихсл потоков, 
обеспечиван одновременное прохождение ими всех фаз алгоритма. К примеру, 
когда CLR задеиствует сервернуго версиго уборшика мусора, его алгоритм создает 
один поток исполненин длл каждого лдра. Зти потоки проходлт через различнвге 
стеки приложенин, одновременно помечан обБектБ 1 в куче. Завершив свок> порцшо 
работБ1, поток должен остановитБСн и подождатБ завершенгш работБ1 осталБНБ1х. 
Когда все потоки пометлт обБектБ 1 , они смогут одновременно приступитв к сжатшо 
различнБ 1 х частеи кучи. Поток, закончившии сжиматв кучу, следует заблокироватк, 
что 6 б 1 он дождалсл завершенгш осталвнБ 1 х потоков. Потом все потоки одновре- 
менно проидут через стек потоков приложенгш, присваивал корннм ссбшки на 
новБге местоположенин сжатБ 1 х обвектов. И толбко после завершенгш всех потоков 
делтелвностБ сборгцика мусора считаетсл оконченнои и понвлиетсл возможностб 
восстановитБ поток приложешш. 

ДаннБш сценарии легко реализуетсл при помогци класса Barrier, которнш 
ВБ1ГЛЛДИТ следуклцим образом (некоторБге перегруженшле версии методов не по- 
казанБ 1 ): 

public class Bannien : IDisposable { 

public Bannien(Int32 panticipantCount, Action<Bannien> postPhaseAction); 

public void Dispose(); 

public Int64 AddPanticipants(Int32 panticipantCount); // Добавление 

// участников 

public void RemovePanticipants(Int32 panticipantCount); // Удаление 

// участников 

public Boolean SignalAndWait( 

Int32 millisecondsTimeout, CancellationToken cancellationToken); 


public Int64 CunnentPhaseNumben { get; } // Показмвает фазм процесса 
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// (начинан с 0) 

public Int32 ParticipantCount { get; } // Количество участников 

public Int32 ParticipantsRemaining { get; } // Число потокоВј необходимнх 

// длн вмзова SignalAndWait 

} 

При конструировании класса Barrien указмваетсл количество потоков, ко- 
торме будут приниматБ участие в работе. Можно также передатБ конструктору 
делегата Action<Barrier>, ссБшакчцегоси на код, которкш будет вБ13ван после 
завершенгш всеми участниками очереднои фазвк Динамически добавлитБ потоки 
к классу Barrier и удалнтБ их оттуда можно при помогци методов AddParticipant 
и RemoveParticipant, но на практике зто делаетсл краине редко. Завершившии 
свок) фазу работБ 1 поток должен вбшвдтб метод SignalAndWait, которБ 1 и за- 
ставит метод Barrier заблокироватв даннБш поток (с помогцбк) конструкции 
ManualResetEventSlim). После вБгзова метода SignalAndWait всеми участниками 
метод Barrier вБ13Б1вает делегата (с помогцбго последнего обрагцавшегосн к методу 
SignalAndWait потока) и снимает блокировку со всех потоков, давал им возмож- 
ностб переити к следугошеи фазе. 

Вмводм по гибриднмм конструкцивм 

И рекомендуго по возможности избегатв кода, блокиругогцего потоки. Вбшолннп 
асинхроннБге вБгчисленип или операции ввода-вБгвода, передаваите даннвге от 
одного потока к другому так, что6бг исклгочитб одновременнуго попвгтку доступа 
к даннБш со сторонБг несколБКих потоков. Если зто невозможно, исполвзуите 
методБг классов Volatile и Interlocked, так как они работагот бвгстро и не блоки- 
ругот потоки. К сожалениго, они подходлт толбко длл работкг с простБши типами. 
Впрочем, даже в зтом случае bbi можете вбшолнитб достаточно сложнбш операции, 
описаннБге в предввдугцеи главе. 

Две основнБШ причинБц по которБш приходитсл блокироватБ потоки: 

□ Упрош,ение модели программировании. Блокируи поток, bki жертвуете ресур- 
сами и производителБностБГО, но получаете возможностб писатБ код последо- 
вателБно, не прибеган к методам обратного вБгзова. Асинхроннвге функции C# 
предоставлигот упрогценнуго моделв программированил без необходимости 
блокировангш потоков. 

□ Поток имеет определенное назначение. Некоторвге потоки исполвзуготсл дли 
решенин конкретшлх задач. Лучшии пример такого рода — основнои поток 
приложенгш. Без блокировки он рано или поздно вернет управление, и процесс 
завершитсн. Другим примером нвлнетсл поток или потоки графического интер- 
феиса приложешш. Windows требует, чтобвг манипулшцш окнами и злементами 
управленгш осугцествлнл толбко породившии их поток. Позтому периодически 
приходитсн писатв код, блокиругогции GUI -поток до завершенгш каких-то дру- 
гих операции. И толбко после зтого даннБги поток обновлнет окна и злементв! 
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управленил. Разумеетсл, блокировка GUI -потока подвешивает приложение 

и мешает работе полБзователл. 

Чтобм избежатБ блокировки потоков, не стоит ммсленно свнзмватБ их с кон- 
кретнБши операциими. К примеру, не нужно создаватБ поток, провернклции орфо- 
графиго, поток, проверикпции грамматику, поток, обрабатБшакзшии определеннБШ 
клиентские запросБ1 и т. п. Потому что подо 6 нбш подход как 6ki показБшает, что 
поток не может вбшолннтб других операции. Однако потоки ивлиготси слишком 
ценнвш ресурсом, что 6 б 1 ограничиватБ их толбко однои операциеи. Исполкзуите 
пул длн арендБ1 потоков на короткии период времени. Поток из пула может начатв 
с проверки орфографии, затем переити к проверке грамматики, затем заннтБСн об- 
работкои клиентских запросов и т. п. 

Если же вб 1 , несмотрн ни на что, решите блокироватБ потоки, длн синхронизации 
потоков из разнБ1х доменов или процессов исполвзуите конструкции режима ндра. 
Длн атомарного управленил состолнием через набор операции вам потребуетсл класс 
Monitor с закрБ1ТБ1м полем 1 . В качестве алБтернативБ1 можно прибегнутБ к блоки- 
рованиго на чтение-записБ. В обшем случае зто блокирование работает медленнее 
класса Monitor, но оно позволлет одновременно исполннтбси несколБКим потокам 
чтенин, что повБ1шает об 11 iy 10 производителБностБ и минимизирует возможностб 
блокировки потоков. 

Также стараитесв избегатБ рекурсивнБ1х блокировок (особенно блокировок 
чтенил-записи), так как они сервезно снижагот производителБностБ. Впрочем, 
класс Monitor, несмотрл на свого рекурсивностБ, показБшает вБШОкуго произво- 
дителвностБ 2 . Кроме того, стараитесБ не сниматБ блокировку в блоке finally, так 
как вход в блоки обработки исклгочении и вб 1 ход из них негативно сказвшаетсл на 
производителБности. Кроме того, вБвдача исклгоченин при изменении состолнин 
приводит к ситуации, когда другим потокам приходитсн работатв с поврежденнБши 
даннБши, из-за чего резулитат работБ1 приложении становитсл непредсказуемвш 
и возникагот бреши в системе безопасности. 

И, разумеетсл, если ваш код все-таки удерживает блокировку, он не должен 
удерживатв ее слишком долго, так как в резулвтате повБпнаетсл веронтностБ бло- 
кированин потоков. Далее будет показана техника работБ1 с классами коллекции, 
позволнгошаи избежатв длителБного удерживании блокировки. 

Ну и, наконец, длл вБ1числителБНБ1х операции можно исполБЗОватБ заданин (о ко- 
торБ1х мб1 говорили в главе 27), что6б1 о6оитисб без многочисленнБ1х конструкции 
синхронизации. В частности, мне нравитсл, что с каждвш заданием можно свизатБ 


1 Вместо класса Monitor можно восполБзоватћсл чутв более бмстрнм классом SpinLock. 
Но при зтом возможна ситуацил, когда ресурсм процессора начнут тратитвсл впустуго. И с 
моеи точки зренил, класс SpinLock не настолвко превосходит Monitor по скорости, чтобм 
оправдатв его применение. 

2 Частично зто свлзано с тем, что класс Monitor реализован на машинном, а не на управ- 
ллемом коде. 
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одно или несколико других задании, которме начинагот вмполнитбсн средствами 
пула потоков при завершении некои операции. Зто намного лучше, чем блокироватБ 
поток, ожидан завершенин операции. Длн операции ввода-вмвода следует вмзмватБ 
различнБШ методБ1 XxxAsync, которБге заставлнгот ваш код продолжатв вБшолнение 
после завершении операции ввода-ввшода (аналог задании, вБшолннемБ1х по за- 
вершениго операции). 


Блокировка с двоинои проверкои 

Сугцествует известнБиг прием, пазБгвасмми блокировкоп с двопноп проверкоп 
(double-check locking). К нему прибегагот, если нужно отложитб создание однозле- 
ментного обвекта до тех пор, пока он не потребуетсн приложениго — иногда зто 
назБгвагот отложенноп инициализациеп (lazy initialization). Без запроса обвект 
никогда не создаетсл, что зкономит времл и памнтБ. ПроблемБг могут возникнутБ 
при одновременном запросе обљекта несколвкими потоками. Что6бг в резулвтате 
у вас поивилсл всего один обвект, потребуетсл применение некоторого способа 
синхронизации потоков. 

Зтот прием известен вовсе не благодарн своеи ввгдагогцеисл интересности или 
полезности, просто о нем оченБ много писали. Ранише он часто применнлсн при про- 
граммировании на Java, но позже обнаружилосв, что Java не гарантирует стопроцент- 
Hoii работоспособности резулБтата. Документ с описанием зтои проблемБг находитсн 
по адресу www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html. 

Думаго, вб 1 будете радБ1 узнатБ, что благодарн модели памлти и доступу к во- 
латилБНБш поллм (см. главу 29) CLR прекрасно поддерживает блокирование 
с двоинои проверкои. Вот код, демонстриругогции реализациго даннои техники 
на нзБгке С#: 

internal sealed class Singleton { 

// ОбБект s_lock требуетсл длл обеспеченип безопасности 

// в многопоточнои среде. Наличие зтого обљекта предполагает, 

// что длл созданид однозлементного обиекта требуетсл болнше 
// ресурсов, чем длл обБекта System.Object и что зта процедура 
// может вовсе не понадобитнсл. В противном случае проше и зффективнее 
// получитБ однозлементнми обцект в конструкторе класса 
private static readonly Object s_lock = new Object(); 

// Зто поле ссшлаетсл на один обБект Singleton 
private static Singleton s_value = null; 

// Закритми конструктор не дает внешнему коду создаватБ зкземпллрш 
private Singleton() { 

// Код инициализации обБекта Singleton 

} 


продолжение # 
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// Открнтни статическии метод, возврацаклции обБект Singleton 
// (создавал его при необходимости) 
public static Singleton GetSingleton() { 

// Если об^ект Singleton уже созданЈ возврацаем его 
if (s_value != null) return s_value; 

Monitor.Enter(s_lock); // Если не создан, позволлем одному 
// потоку сделати зто 

if (s_value == null) { 

// Если обиекта все еце нет, создаем его 
Singleton temp = new Singleton(); 

// Сохранлем сснлку в переменнои s_value (см. обсуждение далее) 
Volatile.Write(ref s_value, temp); 

} 

Monitor . Exit(s_lock) ; 

// Возврашаем ссмлку на обиект Singleton 
return s_value; 

} 

} 

Принцип блокировки с двоинои проверкои состоит в том, что при вмзове метода 
GetSingleton бмстро проверлетсл поле s_value, чтобм вмиснитб, создан ли обв- 
ект. При положителБном резулћтате проверки метод возврашает ссвшку на обвект. 
В резулвтате отпадает необходимостБ в синхронизации потоков, и приложение 
работает оченв бв1стро. Однако если поток, вБ 13 вавшии метод GetSingleton, не 
обнаруживает обвекта, он прибегает к блокированшо в рамках синхронизации 
потоков, гарантирун, что созданием обвекта будет заниматвсн толбко один поток. 
То естБ снижение производителБности наблгодаетсл толбко после первого запроса 
к однозлементному обвекту. 

Теперв л о 6 ђнснго, почему зтот паттерн не работает в Java. В начале метода 
GetSingleton виртуалБнан машина Java считБшает значение полн s_value в регистр 
процессора и при ввшолнении второи инструкции if ограничиваетсл запросом 
к зтому регистру. В итоге резулвтатом даннои проверки всегда нвлнетсл значение 
true, а зто означает, что в создании обвекта Singleton принимагот участие все по- 
токи. Разумеетсл, зто возможно толбко при условии, что все потоки вБ 13 вали метод 
GetSingleton одновременно, чего в болвшинстве случаев не происходит. Именно 
позтому ошибка столбко времени оставаласв нераспознаннои. 

В CLR ВБ130В лгобого метода блокированин означает установку непреодолимого 
барвера на доступ к памнти: всн записв в переменнБШ должна завершитБСн до зтого 
барБера, а лгобое чтение переменнБ1х может начатБсл толбко после баркера. Длн 
метода GetSingleton зто означает, что повторное чтение полл s_value должно 
6 б 1 тб произведено после ввгоова метода Monitor . Enter; в процессе ввгоова метода 
значение полн нелвзи сохранитБ в регистре. 

Внутри MeTO^aGetSingleton вБИБшаетсн метод Volatile .Write. Предположим, 
что втораи инструкцин if содержит следуклцуго строку кода: 
s_value = new Singleton(); // В идеале хотелоси 6 bi исполвзоватБ зту команду 
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Можно ожидатБ, что компилитор создаст код, вБвделикжцш памнтБ под обвект 
Singleton, вБ 130 вет конструктор длн инициализации полеи данного обвекта и при- 
своит ссБшку на него полго s_value, что6б1 зто значение увидели другие потоки — зто 
назвшаетси публшациеп (publishing). Однако компилнтор может вбџшлитб памнтБ 
под обвект Singleton, назначитк ссбшку переменнои s_value (вбшолнив публи- 
кацшо) и толбко после зтого вБИватБ конструктор. Если в процедуре участвует 
всего один поток, подобное изменение очередности операции не имеет значенгш. 
Но что произоидет, если после публикации ссбшки в поле s_value, но до ввиова 
конструктора другои поток ввшовет метод GetSingleton? Зтот поток обнаружит, что 
значение полн s_value отлично от null и начнет полБЗОватБСн обвектом Singleton, 
хотл его конструктор егце не закончил работу! Подобнуго ошибку краине сложно 
отследитБ, особенно из-за того, что времл ее попвлении случаино. 

Зту проблему решает вбшов метода Interlocked . Exchange. Он гарантирует, что 
ссвшка из переменнои temp будет опубликована в поле s_value толбко после того, 
как конструктор завершит свого работу. АлБтернативнвш способом решенгш про- 
блемБг нвлнетсл пометка полн s_value клгочеввш словом volatile. Записв в такое 
волатилБное (неустоичивое) поле s_value возможна толбко после завершенгш 
конструктора. К сожалениго, то же самое относитсл ко всем процедурам чтенгш во- 
латилБного поли, а так как никакои необходимости в зтом нет, врнд ли стоит идти 
на снижение производителвности без полнои уверенности в полезности зтого. 

В начале зтого раздела н назвал блокировку с двоинои проверкои не особо ггнте- 
реснои. С моеи точки зренин, разработчики исполБзугот зто решение гораздо чагце, 
чем следовало 6 бг. В болБшинстве случаев оно толбко снижает производителБностБ. 
Вот гораздо более простаи версгш класса Singleton с аналогичнвгм предБгдугцеи 
версии поведением, но без блокировангш с двоинои проверкои: 

internal sealed class Singleton { 

private static Singleton s_value = new Singleton(); 

// Закритми конструктор не дает коду вне данного класса 
// создаватБ зкземплнру 
private Singleton() { 

// Код инициализации обцекта Singleton 

} 

// OTKpbiTbin статическии метод, возврацак)ции обцект Singleton 
// (и создакнции его, если зто нужно) 

public static Singleton GetSingleton() { return s_value; } 

} 

Так как CLR автоматически вБгзвгвает конструктор класса при первои по- 
пвгтке получитБ доступ к члену зтого класса, при первом запросе потока к методу 
GetSingleton класса Singleton автоматически создаетсн зкземплнр обвекта. Более 
того, среда CLR гарантирует безопасноств в отношении потоков при ввгзове кон- 
структора класса. Все зто уже о6бнсннлосб в главе 8 . Недостатком такого подхода 
нвлиетсл вбгзов конструктора типа при первом доступе к лгобому члену класса. 
То еств если в типе Singleton определитв другие статические членкг, перваи же 
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попштка доступа к лгобому из них приведет к понвленшо обвекта Singleton. Не- 
которме разработчики обходлт даннуго проблему при помотци вложеннмх классов. 
Рассмотрим третии способ созданип одиночного обвекта Singleton: 

internal sealed class Singleton { 

private static Singleton s_value = null; 

// Закрнтни конструктор не дает коду вне данного 
// класса создавати зкземпллрћ! 
private Singleton() { 

// Код инициализации обцекта Singleton 

} 

// Открнтни статическии метод, возврацаклции обцект Singleton 
// (и создагации erOj если зто нужно) 
public static Singleton GetSingleton() { 
if (s_value != null) return s_value; 

// Создание нового обцекта Singleton и преврашение его в коренц, 

// если зтого еце не сделал другои поток 
Singleton temp = new Singleton(); 

Interlocked.CompareExchange(ref s_value, temp, null); 

// При потере зтого потока второи обцект Singleton 

// утилизируетсл сборциком мусора 

return s_value; // Возврацение сшлки на обцект 

} 


При одновременном вмзове метода GetSingleton различнмми потоками в зтои 
версии кода может поивитбсл два (и более) обвекта Singleton. Однако метод 
Intenlocked .CompaneExchange гарантирует публикацшо в поле s_value толмсо 
однои ссмлки. Лгобои обвект, не преврагцсннми зтим полем в корневои, будет 
утилизирован при первои же сборке мусора. Впрочем, в болћшинстве приложе- 
нии практически никогда не возникает ситуацин одновременного вмзова метода 
GetSingleton разнмми потоками, позтому там врлд ли когда-нибудБ поивитсл 
более одного обвекта Singleton. 

Возможно, вас беспокоит возможностб созданин множественнмх обЂектов 
Singleton, но даннми код имеет массу достоинств. Во-первмх, он оченЂ бмстро ра- 
ботает. Во-втормх, в нем никогда не блокируготсн потоки. ВедБ когда поток из пула 
блокируетсл на обвекте Moniton или на лгобои другои конструкции синхронизации 
потоков режима лдра, пул порождает еше один поток, чтобм загрузитБ процессор. 
Вмделлетсн и инициализируетсл дополнителБнан памитБ, а все библиотеки полу- 
чагот уведомление о присоединении нового потока. С методом CompaneExchange 
такого никогда не происходит. Разумеетсл, даннуго технику можно исполБЗОватБ 
толбко при отсутствии побочнБ1х зффектов у конструктора. 

В FCL сугцествует два типа, реализугогцие описаннБШ в данном разделе шаблонБ1 
программировангш. Вот как вбшллдит обобгценнБП! класс System . Lazy (некоторБге 
методБг не показанБг): 
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public class Lazy<T> { 

public Lazy(Func<T> valueFactoryj LazyThneadSafetyMode mode); 
public Boolean IsValueCreated { get; } 
public T Value { get; } 

} 

A вот как он работает; 

public static void Main() { 

// Создание оболочки отложеннои инициализации длн полученил DateTime 
Lazy<String> s = new Lazy<String>( 

() => DateTime.Now.ToLongTimeString(), 

LazyThreadSafetyMode.PublicationOnly); 


Console.WriteLine(s.IsValueCreated); 

Console.WriteLine(s.Value); 
Console.WriteLine(s.IsValueCreated); 

Thread.Sleep(10000); 

Console.WriteLine(s.Value); 

} 


// Возврашаетсл false, так как 
// запроса к Value еше не бмло 
// Внзмваетсн зтот делегат 
// Возврацаетсл true, так как 
// бнл запрос к Value 
// Ждем 10 секунд и снова 
// внводим времн 

// Теперц делегат НЕ BbSbiBaeTCH, 
// резулцтат прежнии 


После запуска данного кода м получил: 

False 

2:40:42 РМ 
True 

2:40:42 РМ (5 Обратите внимание, 10 секунд прошло, а времл осталосц прежним 


Код сконструировал зкземшшр класса Lazy и передал ему один из флагов 
LazyThreadSaf etyMode. Вот как вмгллднт и что означагот даннме флаги: 

public enum LazyThreadSafetyMode { 

None, // Безопасностц в отношении потоков не 

// поддерживаетсл (хорошо длл GUI -приложении) 
ExecutionAndPublication, // Исполцзуетсл блокировка с двоинои проверкои 
PublicationOnly, // Исполцзуетсл метод Interlocked.CompareExchange 

} 

В некотормх ситуацинх с ограниченинми по памнти отсутствует необходимостБ 
в создании зкземплира класса Lazy. Вместо зтого можно восполБЗОватБСн статиче- 
скими методами класса System . Threading . Lazylnitializer. Вот как он вбшлндит: 

public static class Lazylnitializer { 

// Зти два метода исполцзушт Interlocked.CompareExchange 

public static Т EnsureInitialized<T>(ref Т target) where T: class; 

public static T EnsureInitialized<T>( 

ref T target, Func<T> valueFactory) where T: class; 


// Зти два метода передагат syncLock в методш Enter и Exit класса Monitor 
public static T EnsureInitialized<T>( 


продолжение & 
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ref Т targetj ref Boolean initializedj ref Object syncl_ock); 
public static T EnsureInitialized<T>(ref T target, 

ref Boolean initialized, ref Object syncLock, Func<T> valueFactory); 

} 


Возможностб нвно указатБ обвект синхронизации в параметре sync Loc k метода 
Ensurelnitialized позволнет однои блокировкои зашититв сразу несколБКО полеи 
и функции инициализации. 

Пример исполБЗОванин метода из данного класса: 

public static void Main() { 

String name = null; 

// Так как имл равно null, запускаетсп делегат и инициализирует поле имени 
Lazylnitializer.Ensurelnitialized(ref name, () => "leffrey"); 
Console.WriteLine(name); // Внводитсл "leffrey" 

// Так как имв отлично от null, делегат не запускаетсл и имл не менветсл 
Lazylnitializer.Ensurelnitialized(ref name, () => "Richter"); 
Console.WriteLine(name); // Снова внводитсл "Deffrey" 

} 


Паттерн условнои переменнои 

Предположим, что некии поток ввшолннет код при соблгодении сложного условин. 
Можно просто организоватв зацикливание зтого потока с периодическои проверкои 
условгш. Однако, во-первБ1х, зто пустал трата процессорного времени, во-вторвгх, 
невозможно атомарно проверитв несколБКО переменнБ1х, входнгцих в условие. К сча- 
стбго, сугцествует шаблон программировангш, позволнгогции потокам зффективно 
синхронизироватБ свои операцгш на основе сложного условил. Он назвгваетсл 
паттерном условноп переменноп (condition variable pattern), а дли его примененгш 
можно восполБЗОватБСн следугогцими методами класса Monitor: 

public static class Monitor { 

public static Boolean Wait(Object obj); 

public static Boolean Wait(Object obj, Int32 millisecondsTimeout); 

public static void Pulse(Object obj); 
public static void PulseAll(Object obj); 

} 


Вот как ВБ1ГЛИДИТ даннБпг паттерн: 

internal sealed class ConditionVariablePattern { 
private readonly Object m_lock = new Object(); 
private Boolean m_condition = false; 

public void Threadl() { 

Monitor.Enter(m_lock); // Взаимоисклн5чан51цал блокировка 
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// "Атомарнал" проверка сложного условил блокированил 
while ( !m_condition) { 

// Если условие не соблвдаетсл , ждемЈ что его поменлет другои поток 
Moniton.Wait(m_lock); // Ha времл снимаем блокировку., 

// 4To6bi другои поток мог ее получити 


} 


// Условие соблвдено, обрабатмваем даннне... 

Moniton.Exit(m_lock) ; // Снлтие блокировки 

} 

public void Thread2() { 

Monitor.Enter(m_lock) ; // ВзаимоисклкЈчаклцал блокировка 


// Обрабатмваем даннме и изменлем условие... 
m_condition = true; 


// Monitor . Pulse(m_lock) ; // Будим одного ожидакицего ПОСЛЕ отменн блокировки 
Monitor . PulseAll(m_lock) ; // Будим всех ожидакицих ПОСЛЕ отменн блокировки 

Monitor . Exit(m_lock) ; // Снлтие блокировки 

} 

} 

В зтом коде поток, вбшолнлговдии метод Threadl, входит в код взаимоисклго- 
чаготцеи блокировки и осушествллет проверку условин. В данном случае н всего 
лишб проверчго значение полл Boolean, но условие может 6бггб сколб угодно 
сложнБш. К примеру, можно взнтб текугцуго дату и удостоверитБСл, что сеичас 
вторник и март, а заодно проверитв, что коллекцтш состоит из 10 злементов. Если 
условие не соблгодаетсл, поток не зацикливаетсл на проверке, так как зто бвшо 6bi 
напраснои тратои процессорного времени, а вБИБшает метод Wait. ДаннБ1и метод 
снимает блокировку, что6б1 ее мог получитБ другои поток, и приостанавливает 
ВБ 13 Б 1 ВаГОГЦИИ поток. 

Метод Thread2 содержит код, вБшолннемвш вторБш потоком. Он вБИБшает метод 
Enter длн блокировки, обрабатвшает какие-то даннБ 1 е, менпн при зтом состоиние 
условгш, после чего ввгзвшает метод Pulse(All), разблокиругогции поток после 
вБгзова метода Wait. Метод Pulse разблокирует поток, ожидагогции долвше всех 
(если такие имеготсн), в то времи как метод PulseAll разблокирует все ожидагогцие 
потоки (если такие еств). Однако ни один из зтих потоков пока не просвшаетсл. 
Поток, вБшолнпгогции метод Thread2, должен вБгзватБ метод Monitor . Exit, даваи 
шанс другому потоку вбшолнитб блокировку. Кроме того, в резулвтате вБшолненгш 
метода PulseAll потоки разблокируготсн не одновременно. После освобожденгш 
потока, ввгзвавшего метод Wait, он становитси владелвцем блокировки, а так как 
зто взаимоисклгочагогцее блокирование, в каждвги момент времени им может вла- 
детв толбко один поток. Другие потоки имегот шанс получитБ право на блокировку 
толбко после того, как текугции владелец ввгзовет метод Wait или Exit. 
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Проснувшисц, поток, вмполннкнции метод Threadl, снова провернет условие 
в цикле. Если оно все епде не соблгодено, он опнтб вмзмвает метод Wait. В противном 
случае он обрабатмвает даннме и, в конце концов, вмзмвает метод Exit, сниман 
блокировку и даван доступ другим потокам возможностб получитБ ее. Таким образом 
даннБш паттерн позволлет проверитв несколБКО формиругогцих сложное условие 
переменнБ1х при помогци простои логики синхронизации (всего однои блокировки), 
а несколвко ожидагогцих потоков могут разблокироватвсн без нарушенин какои- 
либо логики, хотн при зтом возможна напраснан трата процессорного времени. 

Ниже приведен пример безопаснои в отношении потоков очереди, котораи за- 
ставлнет несколвко потоков встраиватв злементБ 1 в очередв и удалнти их. Обратите 
внимание, что потоки, пБгтагогциесл удалити злемент из очереди, блокируготси до 
момента, пока злемент не становитсл доступнвш длл обработки. 

internal sealed class SynchronizedQueue<T> { 
private readonly Object m_lock = new Object(); 
private readonly Queue<T> m_queue = new Queue<T>(); 

public void Enqueue(T item) { 

Monitor.Enter(m_lock); 

// После постановки алемента в очередБ пробуждаем 
// один/все ожидаккцие потоки 
m_queue.Enqueue(item); 

Monitor.PulseAll(m_lock); 

Monitor.Exit(m_lock); 

} 

public T Dequeue() { 

Monitor.Enter(m_lock); 

// Вмполнлем цикЛј пока очередв не опустеет (условие) 
while (m_queue.Count == 0) 

Monitor.Wait(m_queue); 

// Удаллем злемент из очереди и возврацаем его на обработку 
T item = m_queue.Dequeue(); 

Monitor . Exit(m_lock) ; 
return item; 

} 

} 


Асинхроннал синхронизацил 

Мне не силбио нравитсн все зти конструкции синхронизации потоков, исполвзуго- 
гцие примитивБ! в режиме лдра. Ведв они нужнБ! длл блокировангш потоков, в то 
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времн как создание потока обходитси слишком дорого, чтобм потом он не работал. 
Дли наглндности рассмотрим пример. 

Представете веб-саит, к которому клиентм обрагцаготсл с запросами. Посту- 
пившии запрос начинает обрабатмватБСл потоком из пула. ПустБ клиент хочет 
безопаснБш в отношении потоков способом изменитв даннБ1е на сервере, позтому 
он получает блокировку на чтение-записв длп записи. Представим, что блокирова- 
ние длитсл долго. За зто времн успевает приити егце один клиентскии запрос, длл 
которого пул создает новбш поток, пБ1тагогциисн получитБ блокировку на чтение- 
записв длн чтенгш. ЗапросБг продолжагот поступатп, пул создает дополнителБНБге 
потоки, и все зти потоки блокируготсл. Все свое времл сервер занимаетси созда- 
нием потоков и не может остановитБСи! Такои сервер вообгце не может нормалвно 
масштабироватБСн. 

Все становитсн толбко хуже, когда поток записи снимает блокировку, и одновре- 
менно запускаготсн все заблокированнБге потоки чтенгш. В резулктате относителБно 
неболБшому количеству процессоров нужно как-то обработатв все зто множество 
потоков. Windows попадает в ситуациго постопнного переклгоченгш контекста. 
В резулвтате весБ обвем работБг вБшолнлетсл не так бкгстро, как мог б f>i . 

Многие из проблем, решаемпге при помогци описашшх в зтои главе конструкцгш, 
намного успешнее решаготсл средствами класса Task, рассмотренного в главе 27. 
К примеру, возвмем класс Barnier: длл работкг на каждом зтапе можно 6бшо 6бг 
создатБ группу задангш (обЂектов Task), а после их завершенгш ничто не мешает 
нам продолжитБ работу с дополнителБНБши обЂектами Task. Такои подход имеет 
целБш рлд преимугцеств в сравненгш с конструкцгшми, описаннБши в зтои главе: 

□ Задангш требугот менвше памнти, чем потоки, кроме того, они намного бкгстрее 
создаготсл и уничтожаготсп. 

□ Пул потоков автоматически распределлет задангш среди доступнвгх процессо- 
ров. 

□ По мере того как каждое задание завершает свои зтап, вбшолннвшгш его поток 
возврагцаетсл в пул, где может занитБСи другои работои, если такован имеетсл. 

□ Пул потоков видит все задангш сразу и позтому может лучше планироватв их 
вБшолнение, сокрагцап количество потоков в процессе, а значит, и количество 
переклгоченгш контекста. 

Блокировки популнрнБг, но при удержангш в течение долгого времени они 
создагот сервезнБге проблемБг с масштабированием. Ббшо 6бг оченБ полезно иметБ 
асинхроннБге конструкции синхронизацгш, в которвгх ваш код сообгцает о том, что 
он хочет получитБ блокировку. Если получитБ ее не удалосБ, он просто возврагцает 
управление длл ввшолненгш другои работнг (вместо блокировангш на неопреде- 
ленное времн). Затем, когда блокировка станет доступнои, вБшолнение кода воз- 
обновллетсл, и он может получитв доступ к ресурсу, загцигценному блокировкои. Зта 
иден понвиласБ у менн в процессе решенгш сервезнБгх проблем масштабируемости 
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у одного из наших клиентов. Затем н продал патентнме права Microsoft. В 2009 году 
Патентное управление вмдало патент номер 7 603 502. 

Класс SemaphoreSlim реализует зту идек> в своем методе WaitAsync. Сигнатура 
самои сложнои перегруженнои версии зтого метода вмглидит так: 

public Task<Boolean> WaitAsync(Int32 millisecondsTimeout, 

CancellationToken cancellationToken); 

C неи вм можете синхронизироватБ доступ к ресурсу в асинхронном режиме 
(то естБ без блокированин каких-либо потоков). 

private static async Task 

AccessResourceViaAsyncSynchronization(SemaphoreSlim asyncLock) { 

// TODO: Разместите здесБ лтбои код на ваше усмотрение... 

await asyncLock.WaitAsync(); // Запрос монополбного доступа к ресурсу. 

// Когда управление попадает в зту точку, мш знаем, что никакои другои 
// поток не обратаетсн к ресурсу. 

// TODO: Работа с ресурсом (в монополчном режиме)... 

// Завершив работу с ресурсом, снимаем блокировку, чтобш ресурс 

// стал доступншм длл других потоков. 

asyncLock.Release(); 

// TODO: Разместите здесв лтбои код на ваше усмотрение... 

} 

Метод WaitAsync класса SemaphoreSlim чрезвБгааино полезен, но, конечно, он 
реализует семантику семафора. 06б1чно обвект SemaphoreSlim создаетсн со счет- 
чиком 1, что обеспечивает взаимоисклкзчакчции доступ к загцигцаемому ресурсу. 
Таким образом, реализуемое поведение сходно с тем, которое достигаетсл при 
исполБЗОвании Monitor — не считаи того, что SemaphoreSlim не предоставллет 
семантики рекурсии и владенгш потоками (впрочем, зто хорошо). 

А что делатБ с семантикои чтенгш/записи? В ,NET Framework входит класс 
ConcurrentExclusiveSchedulerPair, которвш вбшллдит примерно так: 

public class ConcurrentExclusiveSchedulerPair { 
public ConcurrentExclusiveSchedulerPair(); 

public TaskScheduler ExclusiveScheduler { get; } 
public TaskScheduler ConcurrentScheduler { get; } 

// Другие методш не показанш 

} 

Зкземплир зтого класса содержит два обвекта TaskScheduler, которвш со- 
вместно реализугот семантику чтешш/записи при планировании задании. Все за- 
дашш, запланированшле с исполвзованием ExclusiveScheduler, вбшолннготсл по 
одному — при отсутствии вБшолннемБ1х задач, запланированнБ1х с исполБЗОванием 
ConcurrentScheduler. И конечно, все задачи, запланированшле с исполвзованием 
ConcurrentScheduler, могут вбшолннтбсн одновременно — при отсутствии вбшол- 
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ннеммх задании, запланированнмх ExclusiveScheduler. Пример исполБЗОвании 
класса ConcurrentExclusiveSchedulerPair представлен ниже: 

private static void ConcurrentExclusiveSchedulerDemo() { 
var cesp = new ConcurrentExclusiveSchedulerPair(); 
var tfExclusive = new TaskFactory(cesp.ExclusiveScheduler); 
var tfConcurrent = new TaskFactory(cesp.ConcurrentScheduler); 
for (Int32 operation = 0; operation < 5; operation++) { 

var exclusive = operation < 2; II Длл демонстрации создаотсл 

// 2 монополцнмх и 3 параллелцннх заданил 

(exclusive ? tfExclusive : tfConcurrent).StartNew(() => { 

Console.WriteLine("{0} access", exclusive ? "exclusive" : "concurrent"); 

// TODO: Здесц внполнлетсл монополцнал записц или параллелцное чтение... 

}); 

} 

} 

К сожаленшо, .NET Framework не предоставлиет асинхроннмх средств блоки- 
ровки с семантикои чтенин/записи. Впрочем, л создал такои класс, которми назвал 
AsyncOneManyLock. Он исполБзуетсл по тем же принципам, что и SemaphoreSlim: 

private static async Task 

AccessResourceViaAsyncSynchronization(AsyncOneManyLock asyncLock) { 

// TODO: Здесц виполнлетсл лн)бои код. .. 

// Передаите OneManyMode.Exclusive или OneManyMode.Shared 
// в зависимости от нужного параллелнного доступа 

await asyncLock.AcquireAsync(OneManyMode.Shared); // 3anpocnTb обции доступ 
// Когда управление передаетсл в зту точку, потоки, вмполнлгацие 
// записи в ресурс, отсутствутт; другие потоки могут читатн данние 
// TODO: Чтение из ресурса... 

// Завершив работу с ресурсом, снимаем блокировку, чтобш ресурс 
// стал доступнмм длл других потоков. 
asyncLock.Release() ; 

// TODO: Здеси вшполннетсл лн)бои код... 

} 


Ниже приведен код моеи реализации AsyncOneManyLock. 

public enum OneManyMode { Exclusive, Shared } 

public sealed class AsyncOneManyLock { 

#region Lock code 

private SpinLock m_lock = new SpinLock(true); // He исполнзуем 

// readonly c SpinLock 

private void Lock() { Boolean taken = false; m_lock.Enter(ref taken); } 

private void Unlock() { m_lock.Exit(); } 

ttendregion 

ttregion Lock state and helper methods 

продолжение & 
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private Int32 m_state = 0; 

private Boolean IsFree { get { return m_state == 0; } } 

private Boolean IsOwnedByWriter { get { return m_state == 1; } } 

private Boolean IsOwnedByReaders { get { return m_state > 0; } } 

private Int32 AddReaders(Int32 count) { return m_state += count; } 

private Int32 SubtractReader() { return m_state; } 

private void MakeWriter() { m_state = 1; } 

private void MakeFree() { m_state = 0; } 

ttendregion 

// Длл отсутствил конкуренции (c целнк) улучшенил производителцности 
// и сокрашенил затрат памлти) 

private readonly Task m_noContentionAccessGranter; 

// Каждми ожидаклции поток записи пробуждаетсл через свои обцект 
// TaskCompletionSource, находвциисл в очереди 

private readonly Queue<TaskCompletionSource<Object>> m_qWaitingWriters = 
new Queue<TaskCompletionSource<Object>>(); 

// Bce ожидакпцие потоки чтенил пробуждаттсл по одному 
// обцекту TaskCompletionSource 

private TaskCompletionSource<Object> m_waitingReadersSignal = 
new TaskCompletionSource<Object>(); 
private Int32 m_numWaitingReaders = 0; 

public AsyncOneManyLock() { 

m_noContentionAccessGranter = Task.FromResult<Object>(null); 

} 


public Task WaitAsync(OneManyMode mode) { 

Task accressGranter = m_noContentionAccessGranter; // Предполагаетсл 

// отсутствие конкуренции 


Lock(); 

switch (mode) { 

case OneManyMode.Exclusive: 
if (IsFree) { 

MakeWriter(); // Без конкуренции 

} else { 

// Конкуренцил: ставим в очередц новое задание записи 
var tcs = new TaskCompletionSource<Object>(); 
m_qWaitingWriters.Enqueue(tcs); 
accressGranter = tcs.Task; 


} 

break; 


case OneManyMode.Shared: 

if (IsFree || (IsOwnedByReaders && m_qWaitingWriters.Count == 0)) { 
AddReaders(l); // Отсутствие конкуренции 
} else { // Конкуренцил 

// Увеличиваем количество ожидатцих задании чтенил 
m_numWaitingReaders++; 
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accressGranter = 

m_waitingReadersSignal.Task.ContinueWith(t => t.Result); 

} 

break; 

} 

Unlock(); 

return accressGranter; 

} 

public void Release() { 

TaskCompletionSource<Object> accessGranter = null; 

Lock(); 

if (IsOwnedByWriter) MakeFree(); // Ушло задание записи 
else SubtractReader(); // Ушло задание чтенин 

if (IsFree) { 

// Если ресурс свободенЈ пробудитв одно ожиданкцее задание записи 
// или все заданил чтенив 
if (m_qWaitingWriters.Count > 0) { 

MakeWriter( ); 

accessGranter = m_qWaitingWriters.Dequeue(); 

} else if (m_numWaitingReaders > 0) { 

AddReaders(m_numWaitingReaders); 
m_numWaitingReaders = 0; 
accessGranter = m_waitingReadersSignal; 

// Создание нового обвекта TCS длл будуцих задании, 

// котормм придетсв ожидатБ 

m_waitingReadersSignal = new TaskCompletionSource<Object>(); 

} 

} 

Unlock( ) ; 

// Пробуждение заданив чтенин/записи вне блокировки снижает 
// веронтноств конкуренции и повмшает производителцностц 
if (accessGranter != null) accessGranter.SetResult(null); 

} 

} 

Как 'A уже упоминал, зтот код вообше не блокирует вмполнение потоков, по- 
сколБку в его внутреннеи реализации не исполБзуготсл конструкции лдра. В нем 
исполБзуетсл класс SpinLock, в реализации которого задеиствованм конструкции 
полБЗОвателБСКого режима. Но если вм вспомните из обсужденин SpinLock в гла- 
ве 29, зтот класс следует исполБЗОватБ толбко дли секции кода, заведомо вмпол- 
ннеммх за короткое и конечное времн. Проанализировав Moii метод WaitAsync, вм 
увидите, что во времл удержангш блокировки л ограничивагосв незначителБнмми 
целочисленнмми вмчисленгшми и сравненинми и, возможно, созданием обвекта 
TaskCompletionSource и его добавлением в очередБ. Все зто не заимет много вре- 
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мени, позтому блокировка заведомо будет удерживатБСн в течение оченв короткого 
промежутка. 

АналогичнБш образом метод Release ограничиваетсл целочисленнБ 1 ми Bbi- 
численгшми, сравнением и, возможно, ввшедением обвекта TaskCompletionSource 
из очереди или его созданием. Все зто тоже происходит оченБ бмстро. Все зто по- 
зволило мне с уверенностБкз исполБЗОватБ SpinLock длн загцитБ 1 доступа к Queue. 
ВБшолнение потоков никогда не блокируетсл, что способствует написаншо мас- 
штабируемого, бБШтрого кода. 


Классн коллекции 

длл параллелБного доступа 

В FCL сугцествует четБфе безопаснБ 1 х в отношении потоков класса коллекции, при- 
надлежаших пространству имен System . Collections . Concurrent: ConcurrentQueue, 
ConcurrentStack, ConcurrentDictionary и ConcurrentBag. Вот как вбшлнднт наи- 
более часто исполБзуемБШ членБГ 

// Обработка злементов по алгоритму FIFO 

public class ConcurrentQueue<T> : IProducerConsumerCollection<T>., 

IEnumerable<T>, ICollection, IEnumerable { 

public ConcurrentQueue(); 

public void Enqueue(T item); 

public Boolean TryDequeue(out T result); 

public Int32 Count { get; } 

public IEnumerator<T> GetEnumerator(); 

} 

// Обработка злементов по алгоритму LIFO 

public class ConcurrentStack<T> : IProducerConsumerCollection<T>j 
IEnumerable<T>j ICollection, IEnumerable { 

public ConcurrentStack(); 

public void Push(T item); 

public Boolean TryPop(out T result); 

public Int32 Count { get; } 

public IEnumerator<T> GetEnumerator(); 

} 

// Несортированнми набор алементов c возможноствт храненил дубликатов 
public class ConcurrentBag<T> : IProducerConsumerCollection<T>, 

IEnumerable<T>j ICollection, IEnumerable { 

public ConcurrentBag(); 

public void Add(T item); 

public Boolean TryTake(out T result); 
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public Int32 Count { get; } 

public IEnumerator<T> GetEnumerator(); 

} 

// Несортированнни набор пар клтч/значение 

public class ConcurrentDictionary<TKey, TValue> : IDictionary<TKeyj TValue>j 
ICollection<KeyValuePair<TKeyj TValue>>, IEnumerable<KeyValuePair<TKey, 

TValue>>, IDictionary, ICollection, IEnumerable { 

public ConcurrentDictionary(); 

public Boolean TryAdd(TKey key, TValue value); 

public Boolean TryGetValue(TKey key, out TValue value); 

public TValue this[TKey key] { get; set; } 

public Boolean TryUpdate( 

ТКеу key, TValue newValue, TValue comparisonValue); 
public Boolean TryRemove(TKey key, out TValue value); 
public TValue AddOrUpdate( 

ТКеу key, TValue addValue, Func<TKey, TValue> updateValueFactory); 
public TValue GetOrAdd(TKey key, TValue value); 
public Int32 Count { get; } 

public IEnumerator<KeyValuePair<TKey, TValue>> GetEnumerator(); 

} 

Зти классм коллекции нвлнготси неблокирукнцими. При попмтке извлечБ несу- 
шествугопдии злемент поток немедленно возврандает управление, а не блокируетси, 
ожидан полвленин злемента. Именно позтому такие методм, как Т ryDequeue, ТгуРор, 
Т гуТаке и Т ryGetValue, при получении злемента возврандагот значение true, а при 
его невозможности — f alse. 

Хоти зти коллекции нвллготсн неблокиругогцими, зто вовсе не означает, что они 
обходлтсн без синхронизации. Класс ConcurrentDictionary внутренне исполкзует 
класс Monitor, но блокировка удерживаетсн толбко на короткое времл, необходи- 
мое длн работБ 1 с злементом коллекции. В то же времн классБ 1 ConcurrentQueue 
и ConcurrentStack длл манипулированил коллекциеи исполБзугот методБ 1 Interlocked 
и позтому обходлтсн вообгце без блокированин. Один обвект ConcurrentBag внутрен- 
не состоит из обвекта мини-коллекции длл каждого потока. При добавлении нового 
злемента методБ1 Interlocked помегцагот его в мини-коллекциго вБ13Бшагондего потока. 
При попБ 1 тке извлечБ злемент его наличие опнтб же провернетсл в мини-коллекции 
вБ13Б1вагогцего потока. При обнаружении злемента задеиствуетси метод класса 
Interlocked. Если же злементв рассматриваемои мини-коллекции отсутствует, ме- 
тодБ 1 класса Monitor извлекагот его из мини-коллекции другого потока. Mbi говорим, 
что имеет место захват (stealing) злемента у другого потока. 

Обратите внимание, что все рассматриваемБ 1 е классБ 1 обладагот методом 
GetEnumerator, о6бшно исполнзуемБш в инструкции C# foreach, но допустимвш 
ивизБже LINQ. Длн классов ConcurrentStack, ConcurrentQueue и ConcurrentBag 
метод GetEnumerator создает снимок содержимого коллекции и возврагцает за- 
фиксированнБШ злементБЦ при зтом реалБное содержимое коллекции уже может 
изменитБСл. Метод GetEnumerator класса ConcurrentDictionary не фиксирует 
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содержимое коллекции, а значит, в процессе просмотра словари его вид может 
поменптБСл; об зтом следует помнитб. Своиство Count возврагцает количество 
злементов в коллекции на момент запроса. Если другие потоки в зто времн до- 
бавлнгот злементБ1 в коллекцгпо или извлекагот их оттуда, возврагценное значение 
может оказатвсп невернБш. 

КлассБг ConcurrentStack, ConcurrentQueue и ConcurrentBag реализугот интер- 
феис IProducerConsumerCollection, которБш вбггллдит следугогцим образом: 

public interface IProducerConsumerCollection<T> : IEnumerable<T>j 
ICollection, IEnumerable { 

Boolean TryAdd(T item); 

Boolean TryTake(out T item); 

T[] ToArray(); 

void CopyTo(T[] аггау, Int32 index); 

} 

JIro6oii реализугогции даннБги интерфеис класс может превратитБСн в блокируго- 
гцуго коллекциго. Поток, добавлнгогции злементБг, блокируетсн, если коллекцгш уже 
заполнена, а поток, удалнгогции злементБг, блокируетсн, если она пуста. Разумеетсн, 
н по возможности старагосБ избегатБ таких коллекции, ведк они предназначенБг 
именно дл 'А блокировки потоков. Длн преобразовангш коллекции в блокиругогцуго 
создаетси класс System . Collections . Concurrent . BlockingCollection, конструк- 
тору которого передаетсн ссвшка на неблокиругогцуго коллекциго. Зтот класс вбг- 
глндит следугогцим образом (некоторБге методБг не показанБг): 

public class BlockingCollection<T> : IEnumerable<T>, ICollection, 

IEnumerable, IDisposable { 
public BlockingCollection( 

IProducerConsumerCollection<T> collection, Int32 boundedCapacity); 

public void Add(T item); 
public Boolean TryAdd( 

T item, Int32 msTimeout, CancellationToken cancellationToken); 
public void CompleteAdding(); 

public T Take(); 
public Boolean TryTake( 

out T item, Int32 msTimeout, CancellationToken cancellationToken); 

public Int32 BoundedCapacity { get; } 
public Int32 Count { get; } 

public Boolean IsAddingCompleted { get; } // true, если вмзван метод 

// AddingComplete 

public Boolean IsCompleted { get; } // true, если вћвван метод 

// IsAddingComplete и Count==0 

public IEnumerable<T> GetConsumingEnumerable( 

CancellationToken cancellationToken); 


public void CopyTo(T[] аггау, int index); 
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public T[] ТоАггауО; 
public void Dispose(); 

} 


При конструировании зкземплира BlockingCollection параметр bounded- 
Capacity показмвает максималБно допустимое количество злементов коллекции. 
Если поток вмзмвает метод Add длн уже заполненнои коллекции, он блокируетсл. 
Впрочем, поток может вмзватБ метод Т nyAdd, передав ему времп задержки (в мил- 
лисекундах) и/или обвект CancellationToken. В резулБтате поток блокируетсл 
до добавленил злемента, окончанин времени ожиданип или отменв 1 обвекта 
CancellationToken (класс CancellationToken подробно рассматривалсп в главе 27). 

Класс BlockingCollection реализует интерфеис IDisposable. В итоге метод 
Dispose вБ13Б1ваетсн длл внутреннеи коллекции и удаллет заодно два обвекта 
SemaphoneSlim, исполвзуемБге классом длн блокировки потоков-производителеи 
и потоков-потребителеи. 

Завершив добавление злементов в коллекцшо, поток-производителв должен 
ББгзватБ метод CompleteAdding. Зто даст поннтб потоку-потребителго, что болкше 
злементов не будет и цикл foneach, исполБзукшцш обвект GetConsumingEnumenable, 
завершитсл. ПоказаннБнг далее код демонстрирует, как организоватБ сценарии 
с участием производителн/потребителл и сигналом о завершении: 

public static void Main() { 

var bl = new BlockingCollection<Int32>(new ConcurrentQueue<Int32>()); 

// Поток пула получает алементи 

ThreadPool.QueueUserWorkItem(ConsumeItems, bl); 

// Добавллем в коллекции 5 злементов 
for (Int32 item = 0; item < 5; item++) { 

Console.WriteLine("Producing: " + item); 
bl.Add(item); 

} 

// Информируем поток-потребителц, что болцше злементов не будет 
bl . CompleteAdding( ); 

Console.ReadLine(); // Длл целеи тестированил 

} 

private static void ConsumeItems(Object o) { 
var bl = (BlockingCollection<Int32>) o; 

// Блокируем до полученил алемента, затем обрабатмваем его 
foreach (var item in bl.GetConsumingEnumerable()) { 

Console.WriteLine("Consuming: " + item); 

} 

// Коллекцил пуста и там болцше не будет злементов 
Console.WriteLine("All items have been consumed"); 

} 
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После вмполненин данного кода н получакх 

Producing: 0 
Producing: 1 
Producing: 2 
Producing: 3 
Producing: 4 
Consuming: 0 
Consuming: 1 
Consuming: 2 
Consuming: 3 
Consuming: 4 

All items have been consumed 

Если Bbi попробуете запуститБ зтот код, строчки Producing (производство) 
и Consuming (потребление) могут 6мтб перемешанм, но строка All items have been 
consumed (все злементм потребленм) всегда будет заммкатћ список вмвода. 

Класс BlockingCollection обладает также статическими методами AddToAny, 
Т ryAddToAny, TakeFromAny и Т ryTakeFromAny. Все они принимагот в качестве параме- 
тров коллекцшо BlockingCollectioncT > [ ], а кроме того, злемент, времн ожидангш 
и обвект CancellationToken. Методм (Try)AddToAny циклически просматривагот 
все коллекции в массиве, пока не обнаруживагот коллекциго, способнуго принптћ 
HOBbni злемент. Методм (Try)TakeFromAny циклически просматривагот все кол- 
лекции до обнаруженгш тои, из которои можно извлечБ злемент. 
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